home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 8_3_04.tro < prev    next >
Text File  |  1991-12-22  |  115KB  |  3,808 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright (~c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v'|.5i'
  22. .ce 1000
  23. APPENDIX\ I
  24. .ce 0
  25. .ce 1000
  26. (to Recommendation X.71)
  27. .EF '%    Fascicle\ VIII.3\ \(em\ Rec.\ X.71''
  28. .OF '''Fascicle\ VIII.3\ \(em\ Rec.\ X.71    %'
  29. .sp 9p
  30. .RT
  31. .ce 0
  32. .ce 1000
  33. \fBPossible sequences of network selection signals\fR 
  34. .sp 1P
  35. .RT
  36. .ce 0
  37. .LP
  38. .rs
  39. .sp 47P
  40. .ad r
  41. \fBAppendix I Figure CCITT 31881 (\*`a l'italienne), p.\fR 
  42. .sp 1P
  43. .RT
  44. .ad b
  45. .RT
  46. .LP
  47. .bp
  48. .ce 1000
  49. APPENDIX\ II
  50. .ce 0
  51. .ce 1000
  52. (to Recommendation X.71)
  53. .sp 9p
  54. .RT
  55. .ce 0
  56. .ce 1000
  57. \fBExamples of network selection signals\fR 
  58. .sp 1P
  59. .RT
  60. .ce 0
  61. .LP
  62. II.1
  63.     \fIFirst example\fR \|(minimum sequence of network selection signals)
  64. .sp 1P
  65. .RT
  66. .PP
  67. This example shows a sequence of minimal length. (The remaining
  68. bits in each complete envelope and the preceding calling signal are not 
  69. shown. The bits are shown in the order of\ b\d7\u, b\d6\u, b\d5\u, b\d4\u, 
  70. b\d3\u, b\d2\u, 
  71. b\d1\u.)
  72. .PP
  73. In this example the country of destination has indicated that it does not 
  74. wish to receive the DCC component of the\ DNIC. 
  75. .RT
  76. .LP
  77. .rs
  78. .sp 37P
  79. .ad r
  80. \fBAppendix II Figure CCITT 28160, p. 
  81. .sp 1P
  82. .RT
  83. .ad b
  84. .RT
  85. .LP
  86. .bp
  87. .sp 1P
  88. .LP
  89. II.2
  90.      \fISecond example\fR \|(a sequence of network selection including closed 
  91. user group characters) 
  92. .sp 9p
  93. .RT
  94. .LP
  95. .rs
  96. .sp 32P
  97. .ad r
  98. \fBAppendix II Figure CCITT 31890, p. 
  99. .sp 1P
  100. .RT
  101. .ad b
  102. .RT
  103. .LP
  104. .bp
  105. .ce 1000
  106. APPENDIX\ III\ (A)
  107. .ce 0
  108. .ce 1000
  109. (to Recommendation X.71)
  110. .sp 9p
  111. .RT
  112. .ce 0
  113. .ce 1000
  114. \fBThrough\(hyconnection procedure\fR 
  115. .sp 1P
  116. .RT
  117. .ce 0
  118. .PP
  119. Called and calling line identification not required (No
  120. \fIconnect\(hywhen\(hyfree\fR \|facility)
  121. .sp 1P
  122. .RT
  123. .LP
  124. .rs
  125. .sp 45P
  126. .ad r
  127. \fBFIGURE Appendix III(A) Figure CCITT 28180, p. 
  128. .sp 1P
  129. .RT
  130. .ad b
  131. .RT
  132. .LP
  133. .bp
  134. .ce 1000
  135. APPENDIX\ III\ (B)
  136. .ce 0
  137. .ce 1000
  138. (to Recommendation X.71)
  139. .sp 9p
  140. .RT
  141. .ce 0
  142. .ce 1000
  143. \fBThrough\(hyconnection procedure\fR 
  144. .sp 1P
  145. .RT
  146. .ce 0
  147. .PP
  148. Called and calling line identification not required
  149. (\fIConnect\(hywhen\(hyfree\fR \|facility, subscriber is busy)
  150. .sp 1P
  151. .RT
  152. .LP
  153. .rs
  154. .sp 45P
  155. .ad r
  156. \fBAppendix III(B) Figure CCITT 28190, p.\fR 
  157. .sp 1P
  158. .RT
  159. .ad b
  160. .RT
  161. .LP
  162. .bp
  163. .ce 1000
  164. APPENDIX\ III\ (C)
  165. .ce 0
  166. .ce 1000
  167. (to Recommendation X.71)
  168. .sp 9p
  169. .RT
  170. .ce 0
  171. .ce 1000
  172. \fBThrough\(hyconnection procedure\fR 
  173. .sp 1P
  174. .RT
  175. .ce 0
  176. .PP
  177. Called line identification not required, calling line
  178. identification required (No \fIconnect\(hywhen\(hyfree\fR facility)
  179. .sp 1P
  180. .RT
  181. .LP
  182. .rs
  183. .sp 45P
  184. .ad r
  185. \fBAppendix III(C) Figure CCITT 28200, p.\fR 
  186. .sp 1P
  187. .RT
  188. .ad b
  189. .RT
  190. .LP
  191. .bp
  192. .ce 1000
  193. APPENDIX\ III\ (D)
  194. .ce 0
  195. .ce 1000
  196. (to Recommendation X.71)
  197. .sp 9p
  198. .RT
  199. .ce 0
  200. .ce 1000
  201. \fBThrough\(hyconnection procedure\fR 
  202. .sp 1P
  203. .RT
  204. .ce 0
  205. .PP
  206. Called line identification not required, calling line
  207. identification required (\fIConnect\(hywhen\(hyfree\fR facility, subscriber 
  208. is busy) 
  209. .sp 1P
  210. .RT
  211. .LP
  212. .rs
  213. .sp 45P
  214. .ad r
  215. \fBAppendix III(D) Figure CCITT 28210, p.\fR 
  216. .sp 1P
  217. .RT
  218. .ad b
  219. .RT
  220. .LP
  221. .bp
  222. .ce 1000
  223. APPENDIX\ III\ (E)
  224. .ce 0
  225. .ce 1000
  226. (to Recommendation X.71)
  227. .sp 9p
  228. .RT
  229. .ce 0
  230. .ce 1000
  231. \fBThrough\(hyconnection procedure\fR 
  232. .sp 1P
  233. .RT
  234. .ce 0
  235. .PP
  236. Called line identification required, calling line
  237. identification not required (No \fIconnect\(hywhen\(hyfree\fR facility)
  238. .sp 1P
  239. .RT
  240. .LP
  241. .rs
  242. .sp 47P
  243. .ad r
  244. \fBAppendix III(E) Figure CCITT 28220, p.\fR 
  245. .ad b
  246. .RT
  247. .LP
  248. .bp
  249. .ce 1000
  250. APPENDIX\ III\ (F)
  251. .ce 0
  252. .ce 1000
  253. (to Recommendation X.71)
  254. .sp 9p
  255. .RT
  256. .ce 0
  257. .ce 1000
  258. \fBThrough\(hyconnection procedure\fR 
  259. .sp 1P
  260. .RT
  261. .ce 0
  262. .PP
  263. Called line identification required, calling line
  264. identification not required (\fIConnect\(hywhen\(hyfree\fR facility, subscriber 
  265. is busy) 
  266. .sp 1P
  267. .RT
  268. .LP
  269. .rs
  270. .sp 47P
  271. .ad r
  272. \fBAppendix III(F) Figure CCITT 28230, p.\fR 
  273. .ad b
  274. .RT
  275. .LP
  276. .bp
  277. .ce 1000
  278. APPENDIX\ III\ (G)
  279. .ce 0
  280. .ce 1000
  281. (to Recommendation X.71)
  282. .sp 9p
  283. .RT
  284. .ce 0
  285. .ce 1000
  286. \fBThrough\(hyconnection procedure\fR 
  287. .sp 1P
  288. .RT
  289. .ce 0
  290. .PP
  291. Called and calling line identification required (No
  292. \fIconnect\(hywhen\(hyfree\fR \|facility)
  293. .sp 1P
  294. .RT
  295. .LP
  296. .rs
  297. .sp 47P
  298. .ad r
  299. \fBAppendix III(G) Figure CCITT 28240, p. \fR 
  300. .ad b
  301. .RT
  302. .LP
  303. .bp
  304. .ce 1000
  305. APPENDIX\ III\ (H)
  306. .ce 0
  307. .ce 1000
  308. (to Recommendation X.71)
  309. .sp 9p
  310. .RT
  311. .ce 0
  312. .ce 1000
  313. \fBThrough\(hyconnection procedure\fR 
  314. .sp 1P
  315. .RT
  316. .ce 0
  317. .PP
  318. Called and calling line identification required
  319. (\fIConnect\(hywhen\(hyfree\fR \|facility, subscriber is busy)
  320. .sp 1P
  321. .RT
  322. .LP
  323. .rs
  324. .sp 47P
  325. .ad r
  326. \fBAppendix III(H) Figure CCITT 28250, p.\fR 
  327. .ad b
  328. .RT
  329. .LP
  330. .bp
  331. .ce 1000
  332. APPENDIX\ IV
  333. .ce 0
  334. .ce 1000
  335. (to Recommendation X.71)
  336. .sp 9p
  337. .RT
  338. .ce 0
  339. .ce 1000
  340. \fBUnsuccessful call\fR 
  341. .sp 1P
  342. .RT
  343. .ce 0
  344. .LP
  345. .rs
  346. .sp 47P
  347. .ad r
  348. \fBAppendix IV Figure CCITT 28260, p.\fR 
  349. .sp 1P
  350. .RT
  351. .ad b
  352. .RT
  353. .LP
  354. .bp
  355. .ce 1000
  356. APPENDIX\ V
  357. .ce 0
  358. .ce 1000
  359. (to Recommendation X.71)
  360. .sp 9p
  361. .RT
  362. .ce 0
  363. .ce 1000
  364. \fBFormat of signalling characters within the Recommendation X.50\fR 
  365. .sp 1P
  366. .RT
  367. .ce 0
  368. .PP
  369. An example of three successive signalling characters within
  370. five octets of one channel of the Recommendation\ X.50 multiplex
  371. structure.
  372. \v'4p'
  373. .sp 1P
  374. .RT
  375. .sp 1P
  376. .ce 1000
  377. F\ \ b\d2\u\ \ b\d2\u\ \ b\d2\u\ \ 
  378. a\d1\u\ \ a\d2\u\ \ a\d3\u\ \ 0
  379. .ce 0
  380. .sp 1P
  381. .ce 1000
  382. F\ \ a\d4\u\ \ a\d5\u\ \ a\d6\u\ \ a\d7\u\ \ a\d8\u\ \ b\d1\u\ \ 0
  383. .ce 0
  384. .sp 1P
  385. .ce 1000
  386. F\ \ b\d2\u\ \ b\d3\u\ \ b\d4\u\ \ b\d5\u\ \ b\d6\u\ \ b\d7\u\ \ 0
  387. .ce 0
  388. .sp 1P
  389. .ce 1000
  390. F\ \ b\d8\u\ \ c\d1\u\ \ c\d2\u\ \ c\d3\u\ \ c\d4\u\ \ c\d5\u\ \ 0
  391. .ce 0
  392. .sp 1P
  393. .ce 1000
  394. F\ \ c\d6\u\ \ c\d7\u\ \ c\d8\u\ \ b\d5\u\ \ b\d5\u\ \ b\d5\u\ \ 0
  395. .ce 0
  396. .sp 1P
  397. .PP
  398. Status bits are 0s.
  399. \v'4p'
  400. .sp 1P
  401. .ce 1000
  402. a\d1\u.\|.\|. a\d8\uis a signalling character
  403. .ce 0
  404. .sp 1P
  405. .ce 1000
  406. b\d1\u.\|.\|. b\d8\uis a signalling character
  407. .ce 0
  408. .sp 1P
  409. .ce 1000
  410. c\d1\u.\|.\|. c\d8\uis a signalling character
  411. \v'4p'
  412. .ce 0
  413. .sp 1P
  414. .PP
  415. The framing bits F will be assigned on the multiplexed stream
  416. according to Recommendation\ X.50. No alignment of signalling characters with
  417. the envelopes of the multiplex structure is assumed or required.
  418. .sp 2P
  419. .LP
  420. \fBRecommendation\ X.75\fR 
  421. .RT
  422. .sp 2P
  423. .ce 1000
  424. \fBPACKET\(hySWITCHED\ SIGNALLING\ SYSTEM\fR 
  425. .EF '%    Fascicle\ VIII.3\ \(em\ Rec.\ X.75''
  426. .OF '''Fascicle\ VIII.3\ \(em\ Rec.\ X.75    %'
  427. .ce 0
  428. .ce 1000
  429. \fBBETWEEN\ PUBLIC\ NETWORKS\ PROVIDING\fR 
  430. .ce 0
  431. .sp 1P
  432. .ce 1000
  433. \fBDATA\ TRANSMISSION\ SERVICES\fR 
  434. .ce 0
  435. .sp 1P
  436. .ce 1000
  437. \fI(provisional, Geneva, 1978; amended at Geneva, 1980,\fR 
  438. .sp 9p
  439. .RT
  440. .ce 0
  441. .sp 1P
  442. .ce 1000
  443. \fIMalaga\(hyTorremolinos, 1984, and Melbourne, 1988)\fR 
  444. .ce 0
  445. .sp 1P
  446. .PP
  447. The establishment in various countries of public networks
  448. providing packet\(hyswitched data transmission services creates a need to
  449. standardize international interworking.
  450. .sp 1P
  451. .RT
  452. .LP
  453.     The CCITT,
  454. .sp 1P
  455. .RT
  456. .sp 1P
  457. .LP
  458. \fIconsidering\fR 
  459. .sp 9p
  460. .RT
  461. .PP
  462. (a)
  463. that Recommendation X.1 includes specific user classes of service for data 
  464. terminal equipments operating in the packet mode, 
  465. Recommendation\ X.2 defines user facilities, Recommendations X.25, X.28, 
  466. X.29, X.31 and\ X.32 define DTE/DCE interface characteristics and Recommendation\ 
  467. X.96 defines \fIcall progress\fR signals; 
  468. .PP
  469. (b)
  470. that the logical links A1 and G1 in an international
  471. connection are defined in Recommendation\ X.92 for packet\(hyswitched data
  472. transmission services;
  473. .PP
  474. (c)
  475. that Recommendations X.300, X.301 and X.302 define the general principles 
  476. and arrangements for interworking between public data 
  477. networks, and between public data networks and other public networks;
  478. .PP
  479. (d)
  480. that Recommendations X.320, X.322, X.323 and X.325
  481. provide descriptions of interworking cases among networks;
  482. .bp
  483. .LP
  484. .PP
  485. (e)
  486. that Recommendation X.180 defines the administrative
  487. arrangements for International Closed User Groups and that Recommendation\ 
  488. X.181 defines the administrative arrangements for the provision of international 
  489. Permanent Virtual Circuits;
  490. .PP
  491. (f
  492. )
  493. that the necessary elements of the signalling
  494. terminal (STE) interface Recommendation at the gateway/transit data switching 
  495. exchange should be defined independently as: 
  496. .LP
  497.     \fIPhysical\ layer\fR     \(em
  498.     the mechanical, electrical,
  499. functional and procedural characteristics to activate, maintain and
  500. deactivate the physical link at the signalling terminal interface;
  501. .LP
  502.     \fILink\ layer\fR     \(em
  503.     the link layer procedures for data
  504. interchange across the interface between the signalling terminals;
  505. .LP
  506.     \fIPacket\ layer\fR     \(em
  507.     the packet format and signalling
  508. procedures for the exchange of packets containing control information and 
  509. user data at the signalling terminal interface; 
  510. .PP
  511. (g)
  512. that Recommendations X.134, X.135, X.136 and X.137
  513. define the quality of service parameters in public networks providing
  514. packet\(hyswitched data transmission services;
  515. .PP
  516. (h)
  517. that Recommendations X.110, X.121, X.122, E.164 and
  518. E.166 describe the routing principles and numbering plans for public networks 
  519. including ISDNs; 
  520. .sp 1P
  521. .LP
  522. \fIunanimously declares\fR 
  523. .sp 9p
  524. .RT
  525. .PP
  526. (1)
  527. that the basic system structure of the signalling and
  528. data transfer procedures in terms of elements, should be as specified in the
  529. Introduction, \fIBasic system structure\fR ;
  530. .PP
  531. (2)
  532. that the mechanical, electrical, functional and
  533. procedural characteristics to activate, maintain and deactivate the physical
  534. link at the signalling terminal interface should be as specified in \(sc\ 
  535. 1 below, \fIPhysical layer \(em Characteristics of the signalling terminal/physical 
  536. circuit\fR \fIinterface\fR ; 
  537. .PP
  538. (3)
  539. that the link layer procedures which operate over the
  540. physical circuits and provide a mechanism for reliable transport of packets 
  541. at the signalling terminal interface should be as specified in \(sc\ 2 
  542. below, \fILink\fR \fIlayer procedures between signalling terminals\fR ; 
  543. .PP
  544. (4)
  545. that the packet signalling procedures for the exchange of call information 
  546. and user data at the signalling terminal interface should be as specified 
  547. in \(sc\ 3 below, \fIPacket layer procedures between signalling\fR 
  548. \fIterminals\fR ;
  549. .PP
  550. (5)
  551. that the packet format for packets exchanged at the
  552. signalling terminal interface should be as specified in \(sc\ 4 below, 
  553. \fIPacket\fR 
  554. \fIformats for virtual calls and permanent virtual circuits\fR ;
  555. .PP
  556. (6)
  557. that the procedure and formats for user facilities and network utilities 
  558. at the signalling terminal interface should be as specified in \(sc\ 5 
  559. below, \fIProcedure and formats for user facilities and network\fR 
  560. \fIutilities\fR .
  561. .sp 1P
  562. .ce 1000
  563. INDEX
  564. .ce 0
  565. .sp 1P
  566. .sp 2P
  567. .LP
  568. 0
  569.     \fIIntroduction\fR 
  570. .sp 1P
  571. .RT
  572. .LP
  573.     0.1
  574.     General
  575. .LP
  576.     0.2
  577.     Elements
  578. .LP
  579.     0.3
  580.     Basic system structure
  581. .sp 1P
  582. .LP
  583. 1
  584.      \fIPhysical layer \(em Characteristics of the signalling terminal/physical\fR 
  585. \fIcircuit interface\fR 
  586. .sp 9p
  587. .RT
  588. .sp 1P
  589. .LP
  590. 2
  591.     \fILink layer procedures between signalling terminals\fR 
  592. .sp 9p
  593. .RT
  594. .LP
  595.     2.1
  596.     Scope and field of application
  597. .LP
  598.     2.2
  599.     Frame structure
  600. .LP
  601.     2.3
  602.     Elements of procedures
  603. .LP
  604.     2.4
  605.     Description of the procedures
  606. .LP
  607.     2.5
  608.     Multilink procedures (MLP)
  609. .bp
  610. .sp 1P
  611. .LP
  612. 3
  613.     \fIPacket layer procedures between signalling terminals\fR 
  614. .sp 9p
  615. .RT
  616. .LP
  617.     3.1
  618.     Procedures for virtual call set\(hyup and clearing
  619. .LP
  620.     3.2
  621.     Procedures for permanent virtual circuit service
  622. .LP
  623.     3.3
  624.     Procedure for data and interrupt transfer
  625. .LP
  626.     3.4
  627.     Procedures for flow control and for reset
  628. .LP
  629.     3.5
  630.     Procedure for restart
  631. .LP
  632.     3.6
  633.     Relationship between layers
  634. .sp 1P
  635. .LP
  636. 4
  637.     \fIPacket formats for virtual calls and permanent virtual circuits\fR 
  638. .sp 9p
  639. .RT
  640. .LP
  641.     4.1
  642.     General
  643. .LP
  644.     4.2
  645.     Call set\(hyup and clearing packets
  646. .LP
  647.     4.3
  648.     Data and interrupt packets
  649. .LP
  650.     4.4
  651.     Flow control and reset packets
  652. .LP
  653.     4.5
  654.     Restart packets
  655. .sp 1P
  656. .LP
  657. 5
  658.     \fIProcedure and formats for user facilities and network utilities\fR 
  659. .sp 9p
  660. .RT
  661. .LP
  662.     5.1
  663.     Description of optional user facilities
  664. .LP
  665.     5.2
  666.     Formats for optional user facilities
  667. .LP
  668.     5.3
  669.     Procedures for network utilities
  670. .LP
  671.     5.4
  672.     Formats for network utilities
  673. .sp 1P
  674. .LP
  675. \fIAnnex\ A\fR     \(em
  676.     Definition of symbols for Annexes B, C and D
  677. .sp 9p
  678. .RT
  679. .LP
  680. \fIAnne\ \ B\fR     \(em
  681.     State Diagrams for the packet layer interface for a
  682. logical channel between STEs
  683. .LP
  684. \fIAnnex\ C\fR     \(em
  685.     Actions taken by the STE on receipt of packets in a
  686. given state of the packet layer X/Y\ interface
  687. .LP
  688. \fIAnnex\ D\fR     \(em
  689.     Actions taken by the STE on time\(hyouts in the packet
  690. layer
  691. .LP
  692. \fIAnnex\ E\fR     \(em
  693.     Coding of network generated diagnostic fields in X.75
  694. \fIclear\fR , \fIreset\fR and \fIrestart\fR packets
  695. .LP
  696. \fIAnnex\ F\fR     \(em
  697.     Association of Error Conditions with cause and
  698. diagnostic codes.
  699. .LP
  700. \fIAppendix\ I\fR     \(em
  701.     Examples of multilink resetting procedures
  702. .LP
  703. \fB0\fR     \fBIntroduction\fR 
  704. .sp 1P
  705. .RT
  706. .sp 1P
  707. .LP
  708. 0.1
  709.     \fIGeneral\fR 
  710. .sp 9p
  711. .RT
  712. .PP
  713. This Recommendation defines the characteristics and operation of a signalling 
  714. system for use on interconnecting links between various types of 
  715. public networks to provide internetwork data transmission services. It 
  716. permits the transfer of call control and network control information and 
  717. user 
  718. traffic.
  719. .PP
  720. The Recommendation applies to all links between packet\(hyswitched public 
  721. data networks in different countries and also in a number of cases of 
  722. international links with ISDNs as specified in Recommendation\ X.300. These
  723. include links between ISDNs and packet\(hyswitched public data networks 
  724. and links between ISDNs providing packet\(hyswitched data transmission 
  725. services as defined in Recommendation\ X.31. It may also be used on such 
  726. links where the two public networks are in the same country. 
  727. .PP
  728. Each internetwork link comprises two directly connected signalling
  729. terminals (STEs) each within a public network. Transmission facilities 
  730. between the two STEs may comprise either one or a number of circuits. Each 
  731. STE is 
  732. associated with one end of one link and is part of an exchange or exchange
  733. function in the public network.
  734. .PP
  735. Certain parts of this Recommendation apply in only a limited range of interworking 
  736. situations; these are clearly indicated in the text. Some concern links 
  737. between public networks in the same country, and others concern links 
  738. where at least one public network is not a packet\(hyswitched data network.
  739. .PP
  740. The protocol elements included in this Recommendation can be used to support 
  741. the Network Layer Service for interworking situations. 
  742. .bp
  743. .RT
  744. .sp 1P
  745. .LP
  746. 0.2
  747.     \fIElements\fR 
  748. .sp 9p
  749. .RT
  750. .PP
  751. The system is made up of communicating elements which function
  752. independently and are therefore defined separately. These elements
  753. are:
  754. .RT
  755. .LP
  756.     a)
  757.     the physical circuits which comprise transmission
  758. facilities, and a set of mechanical, electrical, functional and procedural
  759. interface characteristics between the transmission facilities and the
  760. signalling terminals and which provide a mechanism for information transfer
  761. between two signalling terminals;
  762. .LP
  763.     b)
  764.     the link layer procedures which operate over the physical
  765. circuits and provide a mechanism for reliable transport of packets between 
  766. the two signalling terminals independently of the particular types of physical 
  767. circuit in use;
  768. .LP
  769.     c)
  770.     the packet layer procedures which use the link layer
  771. procedures and provide a mechanism for the exchange of call control information 
  772. and user traffic between the two signalling terminals. 
  773. .sp 1P
  774. .LP
  775. 0.3
  776.     \fIBasic system structure\fR 
  777. .sp 9p
  778. .RT
  779. .PP
  780. The basic system structure of the signalling procedures, in terms of the 
  781. elements, is shown in 
  782. Figure\ 1/X.75.
  783. .RT
  784. .LP
  785. .rs
  786. .sp 16P
  787. .ad r
  788. \fBFigure 1/X.75, p.\fR 
  789. .sp 1P
  790. .RT
  791. .ad b
  792. .RT
  793. .PP
  794. \fINote\fR \ \(em\ Applicable to this Recommendation:
  795. .LP
  796.     a)
  797.      STE\(hyX denotes the STE of the exchange under consideration on the link 
  798. concerned; 
  799. .LP
  800.     b)
  801.     STE\(hyY denotes the STE of the other exchange under
  802. consideration on the link;
  803. .LP
  804.     c)
  805.     the STE\(hyX/STE\(hyY interface is abbreviated to the X/Y
  806. interface;
  807. .LP
  808.     d)
  809.      multiple X/Y interfaces may be used between two networks. In this case, 
  810. each X/Y\ interface behaves according to the physical, link and 
  811. packet layer formats and procedures within this Recommendation.
  812. .sp 2P
  813. .LP
  814. \fB1\fR     \fBPhysical layer \(em Characteristics of the signalling
  815. terminal/physical circuit interface\fR 
  816. .sp 1P
  817. .RT
  818. .PP
  819. The characteristics of the signalling terminal/physical circuit
  820. interface, defined as the physical layer element, shall be in accordance 
  821. with Recommendation\ G.703, for physical circuits having a bearer rate 
  822. of 64\ kbit/s and optionally, by bilateral agreement, 2048\ Mbit/s (see 
  823. Note). In addition, 
  824. Administrations may use for digital circuits any other recognized rate (e.g.
  825. 1544\ Mbit/s, see Note) by bilateral agreement.
  826. .PP
  827. However, for an interim period by bilateral agreement, any other
  828. recognized rates could be used for analogue circuits, in which case the
  829. characteristics of the signalling terminal/physical circuit interface shall 
  830. be in accordance with the appropriate V\(hySeries Recommendations. 
  831. .bp
  832. .PP
  833. Each physical circuit of the link must be capable of supporting duplex 
  834. operation. 
  835. .PP
  836. In the case of international interworking between packet\(hyswitched
  837. public data networks, the link is assumed to be data link A1 and/or data
  838. link\ G1 in terms of the hypothetical reference connections defined in
  839. Recommendation\ X.92.
  840. .PP
  841. \fINote\fR \ \(em\ It is for further study whether modifications to the link
  842. layer procedures are required for data signalling rates higher than 64\ 
  843. kbit/s in order to support high throughput. 
  844. .RT
  845. .LP
  846. \fB2\fR     \fBLink layer procedures between signalling terminals\fR 
  847. .sp 1P
  848. .RT
  849. .sp 2P
  850. .LP
  851. 2.1
  852.     \fIScope and field of application\fR 
  853. .sp 1P
  854. .RT
  855. .PP
  856. 2.1.1
  857. In order to provide a mechanism for the reliable transport of packets between 
  858. two signalling terminals, it is necessary to define a procedure which can 
  859. accept and deliver packets to the packet layer when either single 
  860. or multiple physical circuits are employed. A multiplicity of physical 
  861. circuits is required if the effects of circuit failures are not to disrupt 
  862. the packet 
  863. layer operation.
  864. .sp 9p
  865. .RT
  866. .PP
  867. 2.1.2
  868. The Single link procedure (SLP) described in \(sc\(sc\ 2.2 to\ 2.4 is used 
  869. for data interchange over a single physical circuit, conforming to the 
  870. description given in \(sc\ 1, between two STEs. When multiple physical 
  871. circuits are employed in parallel this single link procedure is used independently 
  872. on each circuit and the Multilink procedure (MLP) described in \(sc\ 2.5 
  873. is used for data interchange over these multiple parallel links. In addition, 
  874. when only a single physical circuit is employed, Administrations may agree 
  875. bilaterally to use this multilink procedure over the one link. 
  876. .PP
  877. 2.1.3
  878. Each transmission facility is duplex.
  879. .PP
  880. 2.1.4
  881. The single link procedure is based upon the Link access procedure (LAPB) 
  882. described in \(sc\ 2 of Recommendation\ X.25. The procedure uses the 
  883. principle and terminology of the High level data link control (HDLC) procedure 
  884. specified by the International Organization for Standardization (ISO). 
  885. .PP
  886. The multilink procedure is based on the principle and terminology of the 
  887. multilink procedure specified by\ ISO. 
  888. .PP
  889. 2.1.5
  890. For each SLP employed, either extended mode (modulo 128) or
  891. non\(hyextended mode (modulo\ 8) may be used. The choice of the mode employed 
  892. for such link procedures is independent of all others and of the choice 
  893. of mode for the corresponding packet layer procedures. All choices are 
  894. matters for 
  895. bilateral agreement.
  896. .sp 9p
  897. .RT
  898. .sp 2P
  899. .LP
  900. 2.2
  901.     \fIFrame structure\fR 
  902. .sp 1P
  903. .RT
  904. .PP
  905. 2.2.1
  906. All transmissions are in frames conforming to one of the
  907. formats of Tables\ 1/X.75 and\ 2/X.75. The flag preceding the address field is
  908. defined as the opening flag. The flag following the Frame checking sequence
  909. (FCS) field is defined as the closing flag.
  910. .sp 9p
  911. .RT
  912. .sp 1P
  913. .LP
  914. 2.2.2
  915.     \fIFlag sequence\fR 
  916. .sp 9p
  917. .RT
  918. .PP
  919. All frames shall start and end with the flag sequence consisting
  920. of one 0\ bit followed by six contiguous 1\ bits and one 0\ bit. The STE shall
  921. only send complete and distinct eight\(hybit flag sequences when sending 
  922. multiple flag sequences (see \(sc\ 2.2.11). A single flag may be used as 
  923. both the closing 
  924. flag for one frame and the opening flag for the next frame.
  925. .RT
  926. .sp 1P
  927. .LP
  928. 2.2.3
  929.     \fIAddress field\fR 
  930. .sp 9p
  931. .RT
  932. .PP
  933. The address field shall consist of one octet. The address field
  934. identifies the intended receiver of a command frame and the transmitter of a
  935. response frame. The coding of the address field is described in \(sc\ 2.4.2
  936. below.
  937. .RT
  938. .sp 1P
  939. .LP
  940. 2.2.4
  941.     \fIControl field\fR 
  942. .sp 9p
  943. .RT
  944. .PP
  945. The control field shall consist of one or two octets. The content of this 
  946. field is described in \(sc\ 2.3.2 below. 
  947. .bp
  948. .RT
  949. .ce
  950. \fBH.T. [T1.75]\fR 
  951. .ce
  952. TABLE\ 1/X.75
  953. .ce
  954. \fBFrame formats (modulo 8)\fR 
  955. .ps 9
  956. .vs 11
  957. .nr VS 11
  958. .nr PS 9
  959. .TS
  960. center box;
  961. lw(48p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) .
  962. Bit order of transmission    12345678    12345678    1 to 8    16 to 1    12345678
  963. .T&
  964. cw(36p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) .
  965. Flag    Address    Control    FCS    Flag
  966. _
  967. .T&
  968. cw(36p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) .
  969. F  01111110    A  8 bits    C  8 bits    FCS  16 bits    F  01111110
  970. _
  971. .TE
  972. .nr PS 9
  973. .RT
  974. .ad r
  975. \fBTableau 1/X.75 [T1.75], p.14\fR 
  976. .sp 1P
  977. .RT
  978. .ad b
  979. .RT
  980. .LP
  981. .rs
  982. .sp 18P
  983. .ad r
  984. BLANC
  985. .ad b
  986. .RT
  987. .LP
  988. .bp
  989. .ce
  990. \fBH.T. [T2.75]\fR 
  991. .ce
  992. TABLE\ 2/X.75
  993. .ce
  994. \fBFrame formats (modulo 128)\fR 
  995. .ps 9
  996. .vs 11
  997. .nr VS 11
  998. .nr PS 9
  999. .TS
  1000. center box;
  1001. lw(48p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) .
  1002. Bit order of transmission    12345678    12345678    1 to \ua\d\u)\d    16 to 1    12345678
  1003. .T&
  1004. cw(36p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) .
  1005. Flag    Address    Control    FCS    Flag
  1006. _
  1007. .T&
  1008. cw(36p) | cw(36p) | cw(36p) | cw(36p) | cw(36p) .
  1009. F  01111110    A  8 bits    C  bits \ua\d\u)\d    FCS  16 bits    F  01111110
  1010. _
  1011. .TE
  1012. .nr PS 9
  1013. .RT
  1014. .ad r
  1015. \fBTableau 2/X.75 [T2.75], p.15\fR 
  1016. .sp 1P
  1017. .RT
  1018. .ad b
  1019. .RT
  1020. .sp 1P
  1021. .LP
  1022. 2.2.5
  1023.     \fIInformation field\fR 
  1024. .sp 9p
  1025. .RT
  1026. .PP
  1027. The information field of a frame, when present, follows the control field 
  1028. (see \(sc\ 2.2.4 above) and precedes the frame check sequence (see \(sc\ 
  1029. 2.2.7 
  1030. below). See \(sc\ 2.3.4.9, \(sc\ 2.5.2 and \(sc\ 4 for the various codings 
  1031. and groupings of bits in the information field as used in this Recommendation. 
  1032. .PP
  1033. See \(sc\(sc\ 2.3.4.9 and\ 2.4.8.5 with regard to the maximum information
  1034. field length.
  1035. .RT
  1036. .sp 1P
  1037. .LP
  1038. 2.2.6
  1039.     \fITransparency\fR 
  1040. .sp 9p
  1041. .RT
  1042. .PP
  1043. The STE, when transmitting, shall examine the frame content between the 
  1044. two flag sequences including the address, control, information and FCS 
  1045. fields and shall insert a 0\ bit after all sequences of five contiguous 
  1046. 1\ bits (including the last five bits of the FCS) to ensure that a flag 
  1047. sequence is not simulated. The STE, when receiving, shall examine the frame 
  1048. content and shall discard any 0\ bit which directly follows five contiguous 
  1049. 1\ bits. 
  1050. .bp
  1051. .RT
  1052. .sp 1P
  1053. .LP
  1054. 2.2.7
  1055.     \fIFrame checking sequence (FCS) field\fR 
  1056. .sp 9p
  1057. .RT
  1058. .PP
  1059. The notation used to describe the FCS is based on the property of cyclic 
  1060. codes that a code vector such as\ 1000000100001 can be represented by a 
  1061. polynomial P(\fIx\fR )\ = \fIx\fR \u1\d\u2\d + \fIx\fR \uD\dlFBOCAD10\fR 
  1062. 5 + 1. The elements of an 
  1063. \fIn\fR \(hyelement
  1064. code word are thus the coefficients of a ploynomial of order\ \fIn\fR \ 
  1065. \(em1. In this 
  1066. application, these coefficients can have the value\ 0 or\ 1 and the polynomial
  1067. operations are performed modulo\ 2. The polynomial representing the content 
  1068. of a frame is generated using the first bit received after the frame opening 
  1069. flag as the coefficient of the highest order term. 
  1070. .PP
  1071. The FCS field shall be a 16\(hybit sequence. It shall be the ones
  1072. complement of the sum (modulo\ 2) of:
  1073. .RT
  1074. .LP
  1075.     1)
  1076.     the remainder of \fIx\fR \fI\fI
  1077. \u\fIk\fR\d(\fIx\fR \u1\d\u5\d + \fIx\fR \u1\d\u4\d
  1078. + \fIx\fR \u1\d\u3\d + \fIx\fR \u1\d\u2\d + \fIx\fR \u1\d\u1\d + \fIx\fR 
  1079. \u1\d\u0\d + \fIx\fR \uD\dlFBOCAD10\fR 9 + 
  1080. \fIx\fR \uD\dlFBOCAD10\fR 8 +
  1081. \fIx\fR \uD\dlFBOCAD10\fR 7 + \fIx\fR \uD\dlFBOCAD10\fR 6 + \fIx\fR \uD\dlFBOCAD10\fR 
  1082. 5 + \fIx\fR \uD\dlFBOCAD10\fR 4 + \fIx\fR \uD\dlFBOCAD10\fR 3 + + \fIx\fR 
  1083. \uD\dlFBOCAD10\fR 2\ + \fIx\fR + 1) divided 
  1084. (modulo\ 2) by the generator polynomial \fIx\fR \u1\d\u6\d + \fIx\fR \u1\d\u2\d 
  1085. + 
  1086. \fIx\fR \uD\dlFBOCAD10\fR 5 + 1
  1087. where\ \fIk\fR is the number of bits in the frame existing between, but not
  1088. including, the final bit of the opening flag and the first bit of the FCS,
  1089. excluding bits inserted for transparency; and
  1090. .LP
  1091.     2)
  1092.     the remainder of the division (modulo 2) by the generator
  1093. polynomial \fIx\fR \u1\d\u6\d + \fIx\fR \u1\d\u2\d + \fIx\fR \uD\dlFBOCAD10\fR 
  1094. 5 + 1 of the product of 
  1095. \fIx\fR \u1\d\u6\d by the content of the frame existing between, but not 
  1096. including, 
  1097. the final bit of the opening flag and the first bit of the FCS, excluding 
  1098. bits inserted for transparency. 
  1099. .PP
  1100. As a typical implementation, at the transmitter, the initial
  1101. content of the register of the device computing the remainder of the division 
  1102. is preset to all\ 1s and is then modified by the division by the generator 
  1103. polynomial (as described above) on the address, control and information 
  1104. fields; the ones complement of the resulting remainder is transmitted as 
  1105. the 
  1106. 16\(hybit\ FCS.
  1107. .PP
  1108. As the receiver, the initial content of the register of the device
  1109. computing the remainder is preset to all 1s. The final remainder, after
  1110. multiplication by\ \fIx\fR \u1\d\u6\d and then division (modulo\ 2) by 
  1111. the generator 
  1112. polynomial 
  1113. \fIx\fR \u1\d\u6\d\ +\ \fIx\fR \u1\d\u2\d + \fIx\fR \uD\dlFBOCAD10\fR 5 
  1114. + 1 of the serial 
  1115. incoming
  1116. protected bits and FCS, will be 0001110100001111 (\fIx\fR \u1\d\u5\d through
  1117. \fIx\fR \uD\dlFBOCAD10\fR 0, respectively) in the absence of transmission 
  1118. errors. 
  1119. .PP
  1120. \fINote\fR \ \(em\ Explanatory examples are given in Appendix 1 of
  1121. Recommendation\ X.25.
  1122. .RT
  1123. .sp 1P
  1124. .LP
  1125. 2.2.8
  1126.     \fIOrder of bit transmission\fR 
  1127. .sp 9p
  1128. .RT
  1129. .PP
  1130. Addresses, commands, responses and sequence numbers shall be
  1131. transmitted with the low order bit first (for example, the first bit of the
  1132. sequence number that is transmitted shall have the weight\ 2\(de).
  1133. .PP
  1134. The order of transmitting bits within the information field is not
  1135. specified under \(sc\ 2. The FCS shall be transmitted to the line commencing 
  1136. with the coefficient of the highest term, which is found in bit position\ 
  1137. 16 of the FCS field (see Tables\ 1/X.75 and\ 2/X.75). 
  1138. .PP
  1139. \fINote\fR \ \(em\ In Tables 3/X.75, 4/X.75, 5/X.75, 6/X.75, 7/X.75, 8/X.75
  1140. and\ 10/X.75, bit\ 1 is defined as the low order bit.
  1141. .RT
  1142. .sp 1P
  1143. .LP
  1144. 2.2.9
  1145.     \fIInvalid frames\fR 
  1146. .sp 9p
  1147. .RT
  1148. .PP
  1149. The definition of an invalid frame is described in \(sc\ 2.3.5.3
  1150. below.
  1151. .RT
  1152. .sp 1P
  1153. .LP
  1154. 2.2.10
  1155.     \fIFrame abortion\fR 
  1156. .sp 9p
  1157. .RT
  1158. .PP
  1159. Aborting a frame is performed by transmitting at least seven
  1160. contiguous\ 1s (with no inserted\ 0s).
  1161. .RT
  1162. .sp 1P
  1163. .LP
  1164. 2.2.11
  1165.     \fIInterframe time fill\fR 
  1166. .sp 9p
  1167. .RT
  1168. .PP
  1169. Interframe time fill is accomplished by transmitting contiguous
  1170. flags between frames, i.e.,\ multiple eight\(hybit flag sequences (see
  1171. \(sc\ 2.2.2).
  1172. .RT
  1173. .sp 1P
  1174. .LP
  1175. 2.2.12
  1176.     \fILink channel states\fR 
  1177. .sp 9p
  1178. .RT
  1179. .PP
  1180. A link channel as defined here is the means for transmission for
  1181. one direction.
  1182. .RT
  1183. .sp 1P
  1184. .LP
  1185. 2.2.12.1
  1186.     \fIActive channel state\fR 
  1187. .sp 9p
  1188. .RT
  1189. .PP
  1190. The incoming or outgoing channel is defined to be in an active
  1191. condition when it is receiving or transmitting respectively, a frame, an
  1192. abortion sequence or interframe time fill.
  1193. .bp
  1194. .RT
  1195. .sp 1P
  1196. .LP
  1197. 2.2.12.2
  1198.     \fIIdle channel state\fR 
  1199. .sp 9p
  1200. .RT
  1201. .PP
  1202. The incoming or outgoing channel is defined to be in an idle
  1203. condition when it is receiving or transmitting, respectively, a contiguous\ 1
  1204. state for a period of at least 15\ bit times.
  1205. .PP
  1206. See \(sc\ 2.3.5.5 for a description of STE action when an idle condition 
  1207. exists on its incoming channel for an excessive period of time. 
  1208. .RT
  1209. .sp 2P
  1210. .LP
  1211. 2.3
  1212.     \fIElements of procedures\fR 
  1213. .sp 1P
  1214. .RT
  1215. .PP
  1216. 2.3.1
  1217. The elements of procedures are defined in terms of actions that occur on 
  1218. receipt of frames. 
  1219. .sp 9p
  1220. .RT
  1221. .PP
  1222. A procedure is derived from these elements of procedures and is
  1223. described in \(sc\ 2.4 below. Together, \(sc\(sc\ 2.2 and\ 2.3 form the general
  1224. requirements for the proper management of the link.
  1225. .sp 2P
  1226. .LP
  1227. 2.3.2
  1228.     \fIControl field formats and parameters\fR 
  1229. .sp 1P
  1230. .RT
  1231. .sp 1P
  1232. .LP
  1233. 2.3.2.1
  1234.     \fIControl field formats\fR 
  1235. .sp 9p
  1236. .RT
  1237. .PP
  1238. The control field contains a command or a response, and sequence
  1239. numbers where applicable.
  1240. .PP
  1241. Three types of control field formats (see Tables 3/X.75 and 4/X.75)
  1242. are used to perform numbered information transfer (I\ format), numbered
  1243. supervisory functions (S\ format) and unnumbered control functions
  1244. (U\ format).
  1245. .RT
  1246. .LP
  1247. .sp 3
  1248. .ce
  1249. \fBH.T. [T3.75]\fR 
  1250. .ce
  1251. TABLE\ 3/X.75
  1252. .ce
  1253. \fBControl field formats (modulo 8)\fR 
  1254. .ps 9
  1255. .vs 11
  1256. .nr VS 11
  1257. .nr PS 9
  1258. .TS
  1259. center box;
  1260. cw(36p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
  1261. Control field bits    1    2    3    4    5    6    7    8
  1262. _
  1263. .T&
  1264. cw(36p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
  1265. I format    0        N(S)        P        N(R)    
  1266. _
  1267. .T&
  1268. cw(36p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
  1269. S format    1    0    S    S    P/F        N(R)    
  1270. _
  1271. .T&
  1272. cw(36p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
  1273. U format    1    1    M    M    P/F    M    M    T{
  1274. M
  1275. N(S)
  1276. Transmitter send sequence number (bit 2 = low\(hyorder bit).
  1277. .parag
  1278. N(R)
  1279. Transmitter receive sequence number (bit 6 = low\(hyorder bit).
  1280. .parag
  1281. S
  1282. Supervisory function bit.
  1283. .parag
  1284. M
  1285. Modifier function bit.
  1286. .parag
  1287. P/F
  1288. Poll bit when issued as a command, final bit when issued as a
  1289. response (1 = Poll/Final).
  1290. .parag
  1291. P
  1292. Poll bit (1 = Poll).
  1293. .parag
  1294. T}
  1295. _
  1296. .TE
  1297. .nr PS 9
  1298. .RT
  1299. .ad r
  1300. \fBTable 3/X.75 [T3.75], p.\fR 
  1301. .sp 1P
  1302. .RT
  1303. .ad b
  1304. .RT
  1305. .LP
  1306. .bp
  1307. .ce
  1308. \fBH.T. [T4.75]\fR 
  1309. .ce
  1310. TABLE\ 4/X.75
  1311. .ce
  1312. \fI\fIa)\ Control field formats (modulo 128)\fR 
  1313. .ps 9
  1314. .vs 11
  1315. .nr VS 11
  1316. .nr PS 9
  1317. .TS
  1318. center box;
  1319. cw(36p) | cw(12p) sw(12p) sw(12p) sw(12p) sw(12p) sw(12p) sw(12p) sw(12p) | cw(12p) sw(12p) sw(12p) sw(12p) sw(12p) sw(12p) sw(12p) sw(12p) , ^  | c | c | c | c | c | c | c | c | c | c | c | c | c | c | c | c.
  1320. Control field bits    1st Octet    2nd Octet
  1321.     1    2    3    4    5    6    7    8    9    10    11    12    13    14    15    16
  1322. _
  1323. .T&
  1324. cw(36p) | cw(12p) | cw(84p) | cw(12p) | cw(84p) .
  1325. I format    0    N(S)    P    N(R)
  1326. _
  1327. .T&
  1328. cw(36p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(84p) .
  1329. S format    1    0    S    S    X    X    X    X    P/F    N(R)
  1330. _
  1331. .TE
  1332. .nr PS 9
  1333. .RT
  1334. .ad r
  1335. \fBTable 4/X.75 [T4.75], p.\fR 
  1336. .sp 1P
  1337. .RT
  1338. .ad b
  1339. .RT
  1340. .sp 1P
  1341. .LP
  1342. 2.3.2.1.1
  1343.     \fIInformation transfer format\ \(em\ I\fR 
  1344. .sp 9p
  1345. .RT
  1346. .PP
  1347. The I format is used to perform an information transfer. The
  1348. functions of N(S), N(R) and P/F are independent: i.e.,\ each I\ frame has 
  1349. a N(S), a N(R) which may or may not acknowledge additional I\ frames received 
  1350. by the 
  1351. STE, and a P\ bit.
  1352. .RT
  1353. .sp 1P
  1354. .LP
  1355. 2.3.2.1.2
  1356.     \fISupervisory format\ \(em\ S\fR 
  1357. .sp 9p
  1358. .RT
  1359. .PP
  1360. The S format is used to perform link supervisory control functions such 
  1361. as acknowledge I\ frames, request transmission of I\ frames, and to request 
  1362. a temporary suspension of transmission of I\ frames. The function of N(R) 
  1363. and 
  1364. P/F are independent; i.e.,\ each supervisory frame has an N(R) which may 
  1365. or may not acknowledge additional I\ frames received by the STE, and a 
  1366. P/F bit that may be set to\ 0 or\ 1. 
  1367. .bp
  1368. .RT
  1369. .sp 1P
  1370. .LP
  1371. 2.3.2.1.3
  1372.     \fIUnnumbered format\ \(em\ U\fR 
  1373. .sp 9p
  1374. .RT
  1375. .PP
  1376. The U format is used to provide additional link control functions. This 
  1377. format contains no sequence number but does include a P/F bit that may 
  1378. be set to\ 0 to\ 1. The encoding of the unnumbered commands and responses 
  1379. is as 
  1380. defined in Tables\ 5/X.75 and\ 6/X.75. Unnumbered U\ frames make use of 
  1381. a single octet control field for both modulo\ 8 and extended modulo\ 128 
  1382. operations. 
  1383. However, for an interim period and for extended modulo\ 128 operations only,
  1384. some Administrations may choose after bilateral agreement, the 2\ octet 
  1385. control field coding described in\ b) of Table\ 6/X.75. 
  1386. .RT
  1387. .sp 1P
  1388. .LP
  1389. 2.3.2.2
  1390.     \fIControl field parameters\fR 
  1391. .sp 9p
  1392. .RT
  1393. .PP
  1394. The various parameters associated with the control field formats
  1395. are described below.
  1396. .RT
  1397. .sp 1P
  1398. .LP
  1399. 2.3.2.2.1
  1400.     \fIModulus\fR 
  1401. .sp 9p
  1402. .RT
  1403. .PP
  1404. Each I frame is sequentially numbered and may have the value 0
  1405. through modulus minus\ 1 (where \*Qmodulus\*U is the modulus of the sequence
  1406. numbers). The modulus equals\ 8 or\ 128 and the sequence numbers cycle through
  1407. the entire range.
  1408. .RT
  1409. .LP
  1410. .sp 1P
  1411. .LP
  1412. 2.3.2.2.2
  1413.     \fISend state variable V(S)\fR 
  1414. .sp 9p
  1415. .RT
  1416. .PP
  1417. The send state variable denotes the sequence number of the next
  1418. in\(hysequence I\ frame to be transmitted. The send state variable can 
  1419. take on the value\ 0 through modulus minus\ 1. The value of the send state 
  1420. variable is 
  1421. incremented by\ 1 with each successive I\ frame transmission, but cannot 
  1422. exceed N(R) of the last received I\ or S\ format frame by more than the 
  1423. maximum number of outstanding I\ frames (k). The value of k is defined 
  1424. in \(sc\ 2.4.8.6 below. 
  1425. .RT
  1426. .sp 1P
  1427. .LP
  1428. 2.3.2.2.3
  1429.     \fISend sequence number N(S)\fR 
  1430. .sp 9p
  1431. .RT
  1432. .PP
  1433. Only I frames contain N(S), the send sequence number of transmitted frames. 
  1434. At the time of an in\(hysequence I\ frame is designated for transmission, 
  1435. the value of N(S) is set equal to the value of the send state 
  1436. variable.
  1437. .RT
  1438. .sp 1P
  1439. .LP
  1440. 2.3.2.2.4
  1441.     \fIReceive state variable V(R)\fR 
  1442. .sp 9p
  1443. .RT
  1444. .PP
  1445. The receive state variable denotes the sequence number of the next in\(hysequence 
  1446. I\ frame expected to be received. This receive state variable can 
  1447. take on the values\ 0 through modulus minus\ 1. The value of the receive state
  1448. variable is incremented by\ 1 by the receipt of an error free, in\(hysequence
  1449. I\ frame whose send sequence number N(S) equals the receive state
  1450. variable.
  1451. .RT
  1452. .sp 1P
  1453. .LP
  1454. 2.3.2.2.5
  1455.     \fIReceive sequence number N(R)\fR 
  1456. .sp 9p
  1457. .RT
  1458. .PP
  1459. All I frames and supervisory frames contain N(R), the expected send sequence 
  1460. number of the next received I\ frame. At the time that a frame of the above 
  1461. types is designated for transmission, the value of N(R) is set equal to 
  1462. the current value of the receive state variable. N(R) indicates that the 
  1463. STE 
  1464. transmitting the N(R) has received correctly all I\ frames numbered up to and
  1465. including [N(R)\ \(em\ 1].
  1466. .RT
  1467. .sp 1P
  1468. .LP
  1469. 2.3.2.2.6
  1470.     \fIPoll/Final (P/F) bit\fR 
  1471. .sp 9p
  1472. .RT
  1473. .PP
  1474. All frames contain P/F the Poll/Final bit. In command frames the
  1475. P/F bit is referred to as the P\ bit. In response frames it is referred to as
  1476. the F\ bit.
  1477. .RT
  1478. .sp 1P
  1479. .LP
  1480. 2.3.3
  1481.     \fIFunctions of the Poll/Final bit\fR 
  1482. .sp 9p
  1483. .RT
  1484. .PP
  1485. The Poll bit set to 1 is used by the STE to solicit (poll) a
  1486. response from the other STE. The Final bit set to\ 1 is used by the STE to
  1487. indicate the response frame transmitted by the other STE as a result of the
  1488. soliciting (poll) command.
  1489. .PP
  1490. The use of the P/F bit is described in \(sc\ 2.4.3 below.
  1491. .bp
  1492. .RT
  1493. .sp 1P
  1494. .LP
  1495. 2.3.4
  1496.     \fICommands and responses\fR 
  1497. .sp 9p
  1498. .RT
  1499. .PP
  1500. The following commands and responses will be supported by the STE and are 
  1501. represented in 
  1502. Tables\ 5/X.75 and 6/X.75.
  1503. .PP
  1504. The supervisory function bit encoding 11, and those encodings of the modifier 
  1505. function bits in 
  1506. Tables\ 3/X.75 and 4/X.75 not identified in
  1507. Tables\ 5/X.75 and\ 6/X.75, are identified as \fIundefined or not implemented\fR 
  1508. command and response control fields.
  1509. .PP
  1510. The commands and responses are as follows:
  1511. .RT
  1512. .sp 1P
  1513. .LP
  1514. 2.3.4.1
  1515.     \fIInformation  (I) command\fR 
  1516. .sp 9p
  1517. .RT
  1518. .PP
  1519. The function of the information (I) command is to transfer across a data 
  1520. link sequentially numbered frames containing an information field. 
  1521. .RT
  1522. .sp 1P
  1523. .LP
  1524. 2.3.4.2
  1525.     \fIReceive ready (RR) command and response\fR 
  1526. .sp 9p
  1527. .RT
  1528. .PP
  1529. The Receive ready (RR) supervisory frame is used by the STE
  1530. to:
  1531. .RT
  1532. .LP
  1533.     1)
  1534.     indicate it is ready to receive an I frame;
  1535. .LP
  1536.     2)
  1537.      acknowledge previously received I frames numbered up to and including 
  1538. [N(R)\ \(em\ 1]. 
  1539. .PP
  1540. An RR frame may be used to indicate the clearance of a busy
  1541. condition that was reported by the earlier transmission of an RNR frame 
  1542. by that same STE. In addition to indicating the STE status, the RR\ command 
  1543. with the 
  1544. P\ bit set to\ 1 may be used by an STE to ask for the status of the other\ STE.
  1545. .ce
  1546. \fBH.T. [T5.75]\fR 
  1547. .ce
  1548. TABLE\ 5/X.75
  1549. .ce
  1550. \fBCommands and responses (modulo 8)\fR 
  1551. .ps 9
  1552. .vs 11
  1553. .nr VS 11
  1554. .nr PS 9
  1555. .TS
  1556. center box;
  1557. cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
  1558. 1    2    3    4    5    6    7    8
  1559. .T&
  1560. cw(56p) | cw(50p) | cw(50p) | cw(72p) .
  1561. Format    Command    Response    Encoding
  1562. _
  1563. .T&
  1564. lw(56p) | lw(50p) | lw(50p) | cw(12p) | cw(24p) | cw(12p) | cw(24p) .
  1565. Information transfer    I (information)        0    N(S)    P    N(R)
  1566. _
  1567. .T&
  1568. lw(56p) | lw(50p) | lw(50p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(24p) .
  1569. Supervisory    RR (receive ready)    RR (receive ready)    1    0    0    0    P/F    N(R)
  1570. .T&
  1571. lw(56p) | lw(50p) | lw(50p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(24p) .
  1572.     RNR (receive not ready)    RNR (receive not ready)    1    0    1    0    P/F    N(R)
  1573. .T&
  1574. lw(56p) | lw(50p) | lw(50p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(24p) .
  1575.     REJ (reject)    REJ (reject)    1    0    0    1    P/F    N(R)
  1576. _
  1577. .T&
  1578. lw(56p) | lw(50p) | cw(50p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | lw(6p) .
  1579. Unnumbered    T{
  1580. SABM
  1581. (set asynchronous balanced mode)
  1582. T}    . . 1    . . 1    . . 1    . . 1    . . P    . . 1    . . 0    . . 0    
  1583. _
  1584. .T&
  1585. lw(56p) | cw(50p) | cw(50p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | lw(6p) .
  1586. DISC (disconnect)    1    1    0    0    P    0    1    0        
  1587. _
  1588. .T&
  1589. lw(56p) | cw(50p) | cw(50p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | lw(6p) .
  1590. FRMR (frame reject)    1    1    1    0    F    0    0    1        
  1591. _
  1592. .T&
  1593. lw(56p) | cw(50p) | cw(50p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | lw(6p) .
  1594. T{
  1595. UA
  1596. (unnumbered acknowledgement)
  1597. T}    . . 1    . . 1    . . 0    . . 0    . . F    . . 1    . . 1    . . 0        
  1598. _
  1599. .T&
  1600. lw(56p) | cw(50p) | lw(50p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) .
  1601.         DM (disconnected mode)    1    1    1    1    F    0    0    0
  1602. _
  1603. .TE
  1604. .nr PS 9
  1605. .RT
  1606. .ad r
  1607. \fBTable 5/X.75 [T5.75], p.\fR 
  1608. .sp 1P
  1609. .RT
  1610. .ad b
  1611. .RT
  1612. .LP
  1613. .bp
  1614. .ce
  1615. \fBH.T. [T6.75]\fR 
  1616. .ce
  1617. TABLE\ 6/X.75
  1618. .ce
  1619. \fIa)\ Commands and responses (modulo 128)\fR 
  1620. .ps 9
  1621. .vs 11
  1622. .nr VS 11
  1623. .nr PS 9
  1624. .TS
  1625. center box;
  1626. cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) .
  1627. 1    2    3    4    5    6    7    8    9    10\|to\|16
  1628. .T&
  1629. cw(30p) | cw(48p) | cw(36p) | cw(114p) .
  1630. Format    Command    Response    Encoding
  1631. _
  1632. .T&
  1633. lw(30p) | lw(48p) | lw(36p) | cw(12p) | cw(72p) | cw(12p) | cw(18p) .
  1634. Information transfer    . I (information)        . 0    . N(S)    . P    . N(R)
  1635. _
  1636. .T&
  1637. lw(30p) | lw(48p) | lw(36p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) .
  1638. Supervisory    RR (receive  ready)    RR (receive  ready)    1    0    0    0    0    0    0    0    P/F    N(R)
  1639. .T&
  1640. lw(30p) | lw(48p) | lw(36p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) .
  1641.     RNR (receive not ready)    RNR (receive not ready)    1    0    1    0    0    0    0    0    P/F    N(R)
  1642. .T&
  1643. lw(30p) | lw(48p) | lw(36p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) .
  1644.     REJ (reject)    REJ (reject)    1    0    0    1    0    0    0    0    P/F    N(R)
  1645. _
  1646. .TE
  1647. .nr PS 9
  1648. .RT
  1649. .ad r
  1650. \fBTable 6/X.75 TT6.75], p.\fR 
  1651. .sp 1P
  1652. .RT
  1653. .ad b
  1654. .RT
  1655. .LP
  1656. .bp
  1657. .sp 1P
  1658. .LP
  1659. 2.3.4.3
  1660.     \fIReceive not ready (RNR) command and response\fR 
  1661. .sp 9p
  1662. .RT
  1663. .PP
  1664. The Receive not ready (RNR) supervisory frame is used by the STE to indicate 
  1665. a busy condition; i.e.,\ temporary inability to accept additional 
  1666. incoming I\ frames. I\ frames numbered up to and including [N(R)\ \(em\ 1] are
  1667. acknowledged. I\ frame N(R) and any subsequent I\ frames received, if any, are
  1668. not acknowledged; the acceptance status of these I\ frames will be indicated 
  1669. in subsequent frames. 
  1670. .PP
  1671. In addition to indicating the STE status, the RNR command with the
  1672. P\ bit set to\ 1 may be used by an STE to ask for the status of the
  1673. other\ STE.
  1674. .RT
  1675. .sp 1P
  1676. .LP
  1677. 2.3.4.4
  1678.     \fIReject (REJ) command and response\fR 
  1679. .sp 9p
  1680. .RT
  1681. .PP
  1682. The reject (REJ) supervisory frame is used by the STE to request
  1683. retransmission of I\ frames starting with the frame numbered N(R). I\ frames
  1684. numbered [N(R)\ \(em\ 1] and below are acknowledged. Additional I\ frames 
  1685. pending 
  1686. initial transmission may be transmitted following the retransmitted
  1687. I\ frame(s).
  1688. .PP
  1689. Only one REJ exception condition for a given direction of information transfer 
  1690. may be established at any time. The REJ exception condition is cleared 
  1691. (reset) upon the receipt of an I\ frame with an N(S) equal to the N(R) 
  1692. of the 
  1693. REJ frame.
  1694. .PP
  1695. An REJ frame may be used to indicate the clearance of a busy condition 
  1696. that was reported by the earlier transmission of an RNR frame by that same 
  1697. STE. In addition to indicating the STE status, the REJ command with the 
  1698. P\ bit set 
  1699. to\ 1 may be used by an STE to ask for the status of the other STE.
  1700. .RT
  1701. .sp 1P
  1702. .LP
  1703. 2.3.4.5
  1704.     \fISet asynchronous balanced mode (SABM) command and set\fR 
  1705. \fIasynchronous balanced mode extended (SABME) command\fR 
  1706. .sp 9p
  1707. .RT
  1708. .PP
  1709. The SABM unnumbered command is used to place the addressed STE in the asynchronous 
  1710. balanced mode (AMB) information transfer phase, where all 
  1711. command/response control fields will be one octet in length.
  1712. .PP
  1713. The SABME unnumbered command is used to place the addressed STE in the 
  1714. asynchronous balanced mode information transfer phase, where numbered 
  1715. command/response control fields will be two octets in length and unnumbered
  1716. command response fields will be one octet in length (see \fINote\fR ).
  1717. .PP
  1718. No information field is permitted with the SABM and SABME command. The 
  1719. transmission of a SABM/SABME command indicates the clearance of a busy 
  1720. condition that was reported by the earlier transmission of an RNR frame 
  1721. by that same STE. The STE confirms acceptance of SABM/SABME (modulo\ 8/ 
  1722. modulo\ 128) by the transmission at the first opportunity of an UA response. 
  1723. Upon acceptance of this command both the send state variable and the receive 
  1724. state variable are 
  1725. set to\ 0.
  1726. .PP
  1727. Previously transmitted I frames that are unacknowledged when this
  1728. command is actioned remain unacknowledged.
  1729. .PP
  1730. \fINote\fR \ \(em\ For an interim period, as described in \(sc\ 2.3.2.1.3,
  1731. Administrations may bilaterally agree to use a format that consists of a
  1732. 2\(hyoctet control field.
  1733. .RT
  1734. .sp 1P
  1735. .LP
  1736. 2.3.4.6
  1737.     \fIDisconnect (DISC) command\fR 
  1738. .sp 9p
  1739. .RT
  1740. .PP
  1741. The DISC unnumbered command is used to terminate the mode
  1742. previously set. It is used to inform the STE receiving the DISC command that
  1743. the STE sending the DISC command is suspending operation. No information 
  1744. field is permitted with the DISC command. Prior to actioning the DISC command, 
  1745. the 
  1746. addressed STE confirms the acceptance of DISC by the transmission of an
  1747. UA\ response. The STE sending the DISC enters the disconnected phase when it
  1748. receives the acknowledging UA\ response.
  1749. .PP
  1750. Previously transmitted I frames that are unacknowledged when this
  1751. command is actioned remain unacknowledged.
  1752. .RT
  1753. .sp 1P
  1754. .LP
  1755. 2.3.4.7
  1756.     \fIUnnumbered acknowledge (UA) response\fR 
  1757. .sp 9p
  1758. .RT
  1759. .PP
  1760. The UA unnumbered response is used by the STE to acknowledge the
  1761. receipt and acceptance of the mode\(hysetting commands. Received mode\(hysetting 
  1762. commands are not activated until the UA\ response is transmitted. The
  1763. transmission of an UA\ response indicates the clearance of a busy condition 
  1764. that was reported by the earlier transmission of an RNR frame by that same 
  1765. STE. No information field is permitted with the UA\ response. 
  1766. .bp
  1767. .RT
  1768. .sp 1P
  1769. .LP
  1770. 2.3.4.8
  1771.     \fIDisconnected mode (DM) response\fR 
  1772. .sp 9p
  1773. .RT
  1774. .PP
  1775. The DM unnumbered response is used to report a status where the STE is 
  1776. logically disconnected from the link, and is in the disconnected phase. 
  1777. The DM\ response is sent in this phase in response to the reception of 
  1778. a set mode 
  1779. command, to inform the STE that the STE is still in disconnected phase and
  1780. cannot action a set mode command. No information field is permitted with the
  1781. DM\ response.
  1782. .PP
  1783. An STE in a disconnected phase will monitor received commands and will 
  1784. react to an SABM/SABME command as outlined in 
  1785. \(sc\ 2.4.4 below, and will respond with a DM response with the F\ bit set
  1786. to\ 1 to any other command received with the P\ bit set to\ 1.
  1787. .RT
  1788. .sp 1P
  1789. .LP
  1790. 2.3.4.9
  1791.     \fIFrame reject (FRMR) response\fR 
  1792. .sp 9p
  1793. .RT
  1794. .PP
  1795. The FRMR unnumbered response is used by the STE to report an error condition 
  1796. not recoverable by retransmission of the identical frame, i.e.,\ at 
  1797. least one of the following conditions, which results from the receipt of a
  1798. valid frame:
  1799. .RT
  1800. .LP
  1801.     1)
  1802.      the receipt of a command or a response control field that is undefined 
  1803. or not implemented; 
  1804. .LP
  1805.     2)
  1806.     the receipt of an I frame with an information field which
  1807. exceeds the maximum established length;
  1808. .LP
  1809.     3)
  1810.     the receipt of an invalid N(R);
  1811. .LP
  1812.     4)
  1813.     the receipt of a frame with an information field which is
  1814. not permitted or the receipt of a supervisory or unnumbered frame with
  1815. incorrect length;
  1816. .LP
  1817.     5)
  1818.      the receipt of a supervisory frame with the F bit set to 1, except during 
  1819. a timer recovery condition as described in \(sc\ 2.4.5.9 or except as a 
  1820. reply to a command sent with the P\ bit set to\ 1; 
  1821. .LP
  1822.     6)
  1823.     the receipt of an unexpected UA or DM response;
  1824. .LP
  1825.     7)
  1826.     the receipt of an invalid N(S).
  1827. .PP
  1828. An invalid N(R) is defined as one which points to an I frame which has 
  1829. previously been transmitted and acknowledged or to an I\ frame which has 
  1830. not been transmitted and is not the next sequential I\ frame awaiting transmission. 
  1831. A valid\ N(R) must be within the range from the lowest send sequence number\ 
  1832. N(S) of the still unacknowledged frame(s) to the current STE send state 
  1833. variable 
  1834. included (or to the current internal variable\ \fIx\fR if the STE is in 
  1835. the timer 
  1836. recovery condition as described in \(sc\ 2.4.5.9). This constraint applies 
  1837. even if the STE is in a frame rejection condition. 
  1838. .PP
  1839. An invalid N(S) is defined as an N(S) which is equal to the last
  1840. transmitted N(R)\ +\ \fIk\fR and is equal to the received state variable\ V(R),
  1841. where\ \fIk\fR is the maximum number of outstanding information frames (see
  1842. \(sc\ 2.4.8.6 below).
  1843. .PP
  1844. An information field which immediately follows the control field, and consists 
  1845. of 3\ octets (modulo\ 8) or 5\ octets (modulo\ 128), is returned with this 
  1846. response and provides 
  1847. the reason for the FRMR response. This format is given in Tables\ 7/X.75
  1848. and\ 8/X.75.
  1849. .PP
  1850. For condition 4) listed above, bits W and X should be set to 1.
  1851. .PP
  1852. For conditions 5), 6) and 7) listed above, bit W should be set to 1.
  1853. .PP
  1854. In all cases, the STE receiving the FRMR should examine the contents of 
  1855. the rejected frame control field for further clarification of the cause 
  1856. of the error before recording this error. 
  1857. .RT
  1858. .sp 1P
  1859. .LP
  1860. 2.3.5
  1861.     \fIException condition reporting and recovery\fR 
  1862. .sp 9p
  1863. .RT
  1864. .PP
  1865. The error recovery procedures which are available to effect
  1866. recovery following the detection/occurrence of an exception condition at the
  1867. link layer are described below. Exception conditions described are those
  1868. situations which may occur as the result of transmission errors, STE
  1869. malfunction or operational situations.
  1870. .RT
  1871. .sp 1P
  1872. .LP
  1873. 2.3.5.1
  1874.     \fIBusy condition\fR 
  1875. .sp 9p
  1876. .RT
  1877. .PP
  1878. The busy condition results when an STE is temporarily unable to
  1879. continue to receive I\ frames due to internal constraints, e.g.,\ receive
  1880. buffering limitations. In this case an RNR frame is transmitted from the 
  1881. busy STE. I\ frames pending transmission may be transmitted from the busy 
  1882. STE prior to or following the RNR frame. An indication that the busy condition 
  1883. has 
  1884. cleared is communicated by the transmission of an UA (only in response to a
  1885. SABM/SABME command), RR,\ REJ or SABM/SABME (modulo 8/modulo\ 128) frame.
  1886. .bp
  1887. .RT
  1888. .ce
  1889. \fBH.T. [T7.75]\fR 
  1890. .ce
  1891. TABLE\ 7/X.75
  1892. .ce
  1893. \fBFRMR information field format (modulo 8)\fR 
  1894. .ce
  1895. Information field bits
  1896. .ps 9
  1897. .vs 11
  1898. .nr VS 11
  1899. .nr PS 9
  1900. .TS
  1901. center box;
  1902. cw(54p) | cw(12p) | cw(18p) | cw(18p) | cw(18p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) .
  1903. 1\ 2\ 3\ 4\ 5\ 6\ 7\ 8    9    10 11 12    13    14 15 16    17    18    19    20    21    22    23    24
  1904. _
  1905. .T&
  1906. lw(54p) | cw(12p) | cw(18p) | cw(18p) | cw(18p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(18p) .
  1907. Rejected frame control field    0    V(S)    C/R    V(R)    W    X    Y    Z    0    0    0    T{
  1908. 0
  1909. Rejected frame control field is the control field of the received frame which caused the frame reject.
  1910. .parag
  1911. V(S)\| is the current send state variable value at the STE reporting the
  1912. rejection condition (bit 10 = low\(hyorder bit).
  1913. .parag
  1914. C/R\| set to 1 indicates the rejected frame was a response.
  1915. .parag
  1916. C/R\| set to 0 indicates the rejected frame was a command.
  1917. .parag
  1918. V(R)\| is the current receive state variable value at the STE reporting the
  1919. rejection condition (bit\ 14 = low\(hyorder bit).
  1920. .parag
  1921. W\| set to 1 indicates that the control field received and returned in bits 1
  1922. through 8 was invalid or not implemented.
  1923. .parag
  1924. X\| set to 1 indicates that the control field received and returned in bits\ 1 through 8 was considered invalid because the frame contained an information
  1925. field which is not permitted with this frame or is a supervisory or unnumbered frame with incorrect length. Bit W must be set to 1 in conjunction with this
  1926. bit.
  1927. .parag
  1928. Y\| set to 1 indicates that the information field received exceeded the maximum established capacity.
  1929. .parag
  1930. Z\| set to 1 indicates the control field received and returned in bits 1
  1931. through\ 8 contained an invalid N(R).
  1932. .parag
  1933. Bits 9 and 21 through 24 shall be set to 0.
  1934. .parag
  1935. T}
  1936. _
  1937. .TE
  1938. .nr PS 9
  1939. .RT
  1940. .ad r
  1941. \fBTableau 7/X.75 [T7.75], p.20\fR 
  1942. .sp 1P
  1943. .RT
  1944. .ad b
  1945. .RT
  1946. .ce
  1947. \fBH.T. [T8.75]\fR 
  1948. .ce
  1949. TABLE\ 8/X.75
  1950. .ce
  1951. \fBFRMR information field format (modulo 128)\fR 
  1952. .ce
  1953. Information field bits
  1954. .ps 9
  1955. .vs 11
  1956. .nr VS 11
  1957. .nr PS 9
  1958. .TS
  1959. center box;
  1960. cw(60p) | cw(12p) | cw(24p) | cw(12p) | cw(24p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) .
  1961. 1 to 16    17    18 to 24    25    26 to 32    33    34    35    36    37    38    39    40
  1962. .T&
  1963. lw(60p) | cw(12p) | cw(24p) | cw(12p) | cw(24p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) .
  1964. Rejected frame  control field    0    V(S)    C/R    V(R)    W    X    Y    Z    0    0    0    T{
  1965. 0
  1966. Rejected frame control field is the control field of the received frame which caused the frame reject. When the rejected frame is an unnumbered frame, the
  1967. control field of the rejected frame is positioned in bit positions 1\(hy8, with
  1968. 9\(hy16 set to 0. If, however, the interim solution mentioned in \(sc\ 2.3.2.1.3 is
  1969. adopted, the 2\(hyoctet control field will be placed in bit positions 1\(hy16.
  1970. .parag
  1971. V(S) is the current send state variable value at the STE reporting the
  1972. rejection condition (bit 18\ =\ low order bit).
  1973. .parag
  1974. C/R set to 1 indicates the rejected frame was a response. C/R set to 0
  1975. indicates the rejected frame was a command.
  1976. .parag
  1977. V(R) is the current receive state variable value at the STE reporting the
  1978. rejection condition (bit 26\ =\ low\(hyorder bit).
  1979. .parag
  1980. W set to 1 indicates that the control field received and returned in bits 1
  1981. through 16 was invalid or not implemented.
  1982. .parag
  1983. X set to 1 indicates that the control field received and returned in bits 1
  1984. through 16 was considered invalid because the frame contained an information
  1985. field which is not permitted with this frame or is a supervisory or unnumbered frame with incorrect length. Bit W must be set to 1 in conjunction with this
  1986. bit.
  1987. .parag
  1988. Y set to 1 indicates that the information field received exceeded the maximum established capacity.
  1989. .parag
  1990. Z set to 1 indicates the control field received and returned in bits 1 through 16 contained an invalid N(R).
  1991. .parag
  1992. Bits 17 and 37 through 40 shall be set to 0.
  1993. .parag
  1994. T}
  1995. _
  1996. .TE
  1997. .nr PS 9
  1998. .RT
  1999. .ad r
  2000. \fBTableau 8/X.75 [T8.75], p.21\fR 
  2001. .sp 1P
  2002. .RT
  2003. .ad b
  2004. .RT
  2005. .LP
  2006. .bp
  2007. .sp 1P
  2008. .LP
  2009. 2.3.5.2
  2010.     \fIN(S) sequence error condition\fR 
  2011. .sp 9p
  2012. .RT
  2013. .PP
  2014. The information field of all I frames received whose N(S) does not equal 
  2015. the receive state variable\ V(R) will be discarded. 
  2016. .PP
  2017. An N(S) sequence error exception condition occurs in the receiver when 
  2018. an I\ frame received contains an N(S) which is not equal to the receive 
  2019. state 
  2020. variable\ V(R) at the receiver. The receiver does not acknowledge (increment 
  2021. its receive state variable) the I\ frame causing the sequence error, or 
  2022. any I\ frame which may follow until an I\ frame with the correct\ N(S) 
  2023. is received. 
  2024. .PP
  2025. An STE which receives one or more valid I frames having sequence
  2026. errors
  2027. or subsequent supervisory frames (RR,\ RNR and REJ) shall accept the control
  2028. information contained in the\ N(R) field and the P/F\ bit to perform link 
  2029. control functions; e.g.,\ to receive acknowledgement of previously transmitted 
  2030. I\ frames, and to cause the STE to respond (P\ bit sent to\ 1). 
  2031. .RT
  2032. .sp 1P
  2033. .LP
  2034. 2.3.5.2.1
  2035.     \fIREJ recovery\fR 
  2036. .sp 9p
  2037. .RT
  2038. .PP
  2039. The REJ frame is used by a receiving STE to initiate a recovery
  2040. (retransmission) following the detection of an N(S) sequence error.
  2041. .PP
  2042. With respect to each direction of transmission on the link, only one \fIsent 
  2043. REJ\fR exception condition from an STE is established at a time. A 
  2044. \fIsent REJ\fR exception condition is cleared when the requested I\ frame is
  2045. received.
  2046. .PP
  2047. An STE receiving REJ initiates sequential (re\(hy)transmission of
  2048. I\ frames starting with the I\ frame indicated by the N(R) obtained in the REJ
  2049. frame.
  2050. .PP
  2051. The retransmitted frame(s) may contain an N(R) and a P bit that is
  2052. updated from, and therefore different from, the ones contained in the
  2053. originally transmitted I\ frame(s).
  2054. .RT
  2055. .sp 1P
  2056. .LP
  2057. 2.3.5.2.2
  2058.     \fITime\(hyout recovery\fR 
  2059. .sp 9p
  2060. .RT
  2061. .PP
  2062. If an STE, due to a transmission error, does not receive (or
  2063. receives and discards) a single I\ frame or the last I\ frames in a sequence
  2064. of I\ frames, it will not detect an N(S) sequence error condition and therefore 
  2065. will not transmit an REJ frame. The STE which transmitted the unacknowledged 
  2066. I\ frame(s) shall, following the completion of a system specified time\(hyout
  2067. period (see \(sc\(sc\ 2.4.5.9 and\ 2.4.8.1\ below), take appropriate recovery 
  2068. action to determine at which I\ frame retransmission must begin. The retransmitted 
  2069. frames may contain an N(R) and a P\ bit that are updated from, and therefore 
  2070. different from, the ones contained in the originally transmitted I\ frames. 
  2071. .RT
  2072. .sp 1P
  2073. .LP
  2074. 2.3.5.3
  2075.     \fIInvalid frame condition\fR 
  2076. .sp 9p
  2077. .RT
  2078. .PP
  2079. Any frame which is invalid will be discarded, and no action is
  2080. taken as the result of that frame. An invalid frame is defined as one
  2081. which:
  2082. .RT
  2083. .LP
  2084.     a)
  2085.     is not properly bounded by two flags;
  2086. .LP
  2087.     b)
  2088.     in non\(hyextended (modulo 8) operation, contains fewer than
  2089. 32\ bits between flags; in extended (modulo\ 128) operation,
  2090. contains fewer than 40\ bits between flags of frames that contain
  2091. sequence numbers or 32\ bits between flags of frames that do not
  2092. contain sequence numbers.
  2093. .LP
  2094.     \fINote\fR \ \(em\ Or fewer than 40 bits (modulo 128) if 2\(hyoctet
  2095. control field is used as alternative\ b during the interim
  2096. period (see \(sc\ 2.3.2.1.3).
  2097. .LP
  2098.     c)
  2099.     contains a Frame check sequence (FCS) error;
  2100. .LP
  2101.     d)
  2102.     contains an address other than A or B (for single link
  2103. operation) or other than\ C or\ D (for multilink operation).
  2104. .PP
  2105. For those networks that are octet aligned, a detection of
  2106. non\(hyoctet alignment may be made at the link layer by adding a frame validity
  2107. check that requires the number of bits between the opening flag and the 
  2108. closing flag, excluding bits inserted for transparency, to be an integral 
  2109. number of 
  2110. octets in length, or the frame considered invalid.
  2111. .bp
  2112. .sp 1P
  2113. .LP
  2114. 2.3.5.4
  2115.     \fIFrame rejection condition\fR 
  2116. .sp 9p
  2117. .RT
  2118. .PP
  2119. A frame rejection condition is established upon the receipt of an error\(hyfree 
  2120. frame with one of the conditions listed in \(sc\ 2.3.4.9 above. 
  2121. .PP
  2122. This frame rejection exception condition is reported by sending an
  2123. FRMR response for appropriate STE action.
  2124. .PP
  2125. Once an STE has established a frame rejection condition, no
  2126. additional\ I or S\ format frames are accepted until the condition is reset
  2127. except for examination of the P\ bit. The FRMR response may be repeated 
  2128. at each opportunity, as specified in \(sc\ 2.4.7.3 until recovery is effected 
  2129. by the other STE or until the STE initiates its own recovery in case the 
  2130. other STE does not respond. 
  2131. .RT
  2132. .sp 1P
  2133. .LP
  2134. 2.3.5.5
  2135.     \fIExcessive idle channel state condition on incoming channel\fR 
  2136. .sp 9p
  2137. .RT
  2138. .PP
  2139. Upon detection of an idle channel state condition (see \(sc\ 2.2.12.2 above) 
  2140. on the incoming channel, the STE shall wait for a period\ T3 (see 
  2141. \(sc\ 2.4.8.3 below) without taking any specific action, waiting for detection 
  2142. of a return to the active channel state (i.e.,\ detection of at least one 
  2143. flag 
  2144. sequence). After the period\ T3, the STE shall notify the MLP or the packet
  2145. layer of the excessive idle channel state condition, but shall not take any
  2146. action that would preclude the other STE from establishing the link by 
  2147. normal link set\(hyup procedures. 
  2148. .PP
  2149. The value of T3 is a system parameter and is agreed
  2150. bilaterally.
  2151. .RT
  2152. .sp 2P
  2153. .LP
  2154. 2.4
  2155.     \fIDescription of the procedures\fR 
  2156. .sp 1P
  2157. .RT
  2158. .sp 1P
  2159. .LP
  2160. 2.4.1
  2161.     \fIExtended and non\(hyextended modes of operation\fR 
  2162. .sp 9p
  2163. .RT
  2164. .PP
  2165. Changing from non\(hyextended operation to extended operation,
  2166. or vice versa, requires bilateral agreement and is not supported
  2167. dynamically.
  2168. .PP
  2169. Table 5/X.75 indicates the command and response control field formats used 
  2170. with the non\(hyextended (modulo\ 8) service. The mode setting command 
  2171. employed to initialize (set up) or reset the non\(hyextended mode is the SABM
  2172. command. Table 6/X.75 indicates the command and response control field 
  2173. formats used with the extended (modulo\ 128) service. The mode setting 
  2174. command employed to initialize (set up) or reset the extended mode is the 
  2175. SABME command. 
  2176. .RT
  2177. .sp 1P
  2178. .LP
  2179. 2.4.2
  2180.     \fIProcedure for addressing\fR 
  2181. .sp 9p
  2182. .RT
  2183. .PP
  2184. Commands are sent with the remote STE address and responses are
  2185. sent with the local STE address.
  2186. .PP
  2187. In order to allow differentiation between single link operation and
  2188. multilink operation for diagnostic and/or maintenance reasons, different
  2189. address pair encodings shall be assigned to links operating with the multilink 
  2190. procedure (MLP) compared to links operating with the single link procedure 
  2191. (SLP). These STE addresses are coded as follows;
  2192. .RT
  2193. .LP
  2194. .sp 2
  2195. .ce
  2196. \fBH.T. [T9.75]\fR 
  2197. .ps 9
  2198. .vs 11
  2199. .nr VS 11
  2200. .nr PS 9
  2201. .TS
  2202. center box;
  2203. lw(42p) | cw(24p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) .
  2204.     Address    1    2    3    4    5    6    7    8
  2205. .T&
  2206. lw(42p) | cw(24p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) .
  2207. Single link operation    A    1    1    0    0    0    0    0    0
  2208. .T&
  2209. lw(42p) | cw(24p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) .
  2210.     B    1    0    0    0    0    0    0    0
  2211. .T&
  2212. lw(42p) | cw(24p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) .
  2213. Multilink operation    C    1    1    1    1    0    0    0    0
  2214. .T&
  2215. lw(42p) | cw(24p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) | cw(6p) | cw(12p) .
  2216.     D    1    1    1    0    0    0    0    0
  2217. .TE
  2218. .nr PS 9
  2219. .RT
  2220. .ad r
  2221. \fBTable [T9.75], p.\fR 
  2222. .sp 1P
  2223. .RT
  2224. .ad b
  2225. .RT
  2226. .PP
  2227. .sp 3
  2228. A and B, or C and D, are assigned by bilateral agreement between the Administrations. 
  2229. .bp
  2230. .sp 1P
  2231. .LP
  2232. 2.4.3
  2233.     \fIProcedure for the use of the P/F bit\fR 
  2234. .sp 9p
  2235. .RT
  2236. .PP
  2237. The STE receiving an SABM/SABME, DISC, supervisory command or
  2238. I\ frame with the P\ bit set to\ 1 will set the F\ bit to\ 1 in the next 
  2239. response 
  2240. frame it transmits.
  2241. .PP
  2242. The response frame returned by the STE to an SABM/SABME or DISC
  2243. command with the P\ bit set to\ 1 will be an\ UA or\ DM response with the 
  2244. F\ bit set to\ 1. The response frame returned by the STE to an I\ frame 
  2245. with the P\ bit set to\ 1, received during the information transfer phase, 
  2246. will be an\ RR, REJ, RNR or FRMR response with the F\ bit set to\ 1. The 
  2247. response frame returned by the 
  2248. STE to a supervisory command with the P\ bit set to\ 1, received during the
  2249. information transfer phase, will be an\ RR, REJ, RNR or FRMR response with 
  2250. the F\ bit set to\ 1. 
  2251. .PP
  2252. The response frame returned to an I frame or supervisory frame with
  2253. the P\ bit set to\ 1, received in the disconnected phase, will be a\ DM 
  2254. with F\ bit set to\ 1. 
  2255. .PP
  2256. The P\ bit may be used by the STE in conjunction with the time\(hyout
  2257. recovery condition (see \(sc\ 2.4.5.9 below).
  2258. .PP
  2259. When not used the P/F bit is set to 0.
  2260. .PP
  2261. \fINote\fR \ \(em\ Other use of the P bit by the STE is a subject for further
  2262. study.
  2263. .RT
  2264. .sp 2P
  2265. .LP
  2266. 2.4.4
  2267.     \fIProcedures for link set up and disconnection\fR 
  2268. .sp 1P
  2269. .RT
  2270. .sp 1P
  2271. .LP
  2272. 2.4.4.1
  2273.     \fILink set up\fR 
  2274. .sp 9p
  2275. .RT
  2276. .PP
  2277. The STE will indicate that it is able to set up the link by
  2278. transmitting contiguous flags (active channel state).
  2279. .PP
  2280. Either STE may initialize the link by sending SABM/SABME
  2281. (modulo\ 8/modulo\ 128) and starting Timer\ T1 in order to determine when 
  2282. too much time has elapsed waiting for a reply. The opposite STE upon receiving 
  2283. SABM/SABME correctly, sends\ UA and resets both its state variables to\ 
  2284. 0. If\ UA is received correctly, then the link is set up and the initiating 
  2285. STE resets 
  2286. both its state variables to\ 0 and stops Timer\ T1.
  2287. .PP
  2288. If, upon receipt of SABM/SABME correctly, the STE determines that it cannot 
  2289. enter the indicated phase, it sends the DM\ response. 
  2290. .PP
  2291. When receiving the DM response, the STE which has transmitted an
  2292. SABM/SABME stops its Timer\ T1 and does not enter the information transfer
  2293. phase.
  2294. .PP
  2295. The STE sending SABM/SABME will ignore and discard any frames except SABM/SABME, 
  2296. DISC, UA and\ DM from the other\ STE. 
  2297. .PP
  2298. Frames other than UA and DM in response to a received SABM/SABME will be 
  2299. sent only after the link is set up and if no outstanding SABM/SABME 
  2300. exists.
  2301. .PP
  2302. If an SABM/SABME or DISC command, UA or DM response is not received
  2303. correctly, the result will be that the Timer\ T1 will run out in the STE 
  2304. which originally sent the SABM/SABME and that the STE may resend SABM/SABME 
  2305. and 
  2306. restart Timer\ T1.
  2307. .PP
  2308. After transmission of SABM/SABME N2 times by the STE, appropriate
  2309. recovery action will be initiated.
  2310. .PP
  2311. The value of N2 is defined in \(sc\ 2.4.8.4 below.
  2312. .RT
  2313. .sp 1P
  2314. .LP
  2315. 2.4.4.2
  2316.     \fIInformation transfer phase\fR 
  2317. .sp 9p
  2318. .RT
  2319. .PP
  2320. After having transmitted the UA response to the SABM/SABME command or having 
  2321. received the UA\ response to a transmitted SABM/SABME command, the 
  2322. STE will accept and transmit\ I and supervisory frames according to the
  2323. procedures described in \(sc\ 2.4.5 below.
  2324. .PP
  2325. When receiving an SABM/SABME (modulo 8/modulo 128) command while in
  2326. the information transfer phase, the STE will conform to the resetting procedure 
  2327. described in \(sc\ 2.4.7 below. 
  2328. .bp
  2329. .RT
  2330. .sp 1P
  2331. .LP
  2332. 2.4.4.3
  2333.     \fILink disconnection\fR 
  2334. .sp 9p
  2335. .RT
  2336. .PP
  2337. During the information transfer phase, either STE shall indicate a request 
  2338. for disconnecting the link by transmitting a DISC command, and it shall 
  2339. start Timer\ T1 (see \(sc\ 2.4.8.1 below). 
  2340. .PP
  2341. The STE, on correctly receiving a DISC command, will send a UA\ response 
  2342. and enter the disconnected phase. The STE, on receiving a\ UA or DM\ response 
  2343. to a sent DISC command, stops its timer, and enters the disconnected phase. 
  2344. If 
  2345. a\ UA or DM\ response is not received correctly, this will result in the
  2346. expiration of the Timer\ T1 in the STE which originally sent the DISC command. 
  2347. If Timer\ T1 runs out, this STE will retransmit a DISC command and restart 
  2348. Timer\ T1. This action will continue until a UA\ response or a DM\ response is
  2349. correctly received or until recovery takes place at a higher layer after
  2350. transmission of DISC\ N2 times. The value of\ N2 is defined in \(sc\ 2.4.8.4
  2351. below.
  2352. .RT
  2353. .sp 2P
  2354. .LP
  2355. 2.4.4.4
  2356.     \fIDisconnected phase\fR 
  2357. .sp 1P
  2358. .RT
  2359. .sp 1P
  2360. .LP
  2361. 2.4.4.4.1\ \ After having received a DISC command and returned a UA response, 
  2362. or having received the UA\ response to a transmitted DISC command, the 
  2363. STE will enter the disconnected phase. 
  2364. .sp 9p
  2365. .RT
  2366. .PP
  2367. In the disconnected phase, the STE may initiate link set up. In
  2368. the disconnected phase, the STE will react to the receipt of an SABM/SABME
  2369. command as described in \(sc\ 2.4.4.1 above and will transmit a DM\ response in
  2370. answer to a received DISC command.
  2371. .PP
  2372. When receiving any other command frame (defined, or undefined or not implemented) 
  2373. with the P\ bit set to\ 1, the STE will transmit a DM\ response with the 
  2374. F\ bit set to\ 1. Other frames received in the disconnected phase will 
  2375. be 
  2376. ignored.
  2377. .RT
  2378. .sp 1P
  2379. .LP
  2380. 2.4.4.4.2\ \ After recovery from an internal malfunction, the STE may either 
  2381. initiate a resetting procedure (see \(sc\ 2.4.7 below) or disconnect the 
  2382. link (see \(sc\ 2.4.4.3 above) prior to a link set up procedure (see \(sc\ 
  2383. 2.4.4.1 above). 
  2384. .sp 9p
  2385. .RT
  2386. .sp 1P
  2387. .LP
  2388. 2.4.4.5
  2389.     \fICollision of unnumbered commands\fR 
  2390. .sp 9p
  2391. .RT
  2392. .PP
  2393. Collision situations shall be resolved in the following way.
  2394. .RT
  2395. .sp 1P
  2396. .LP
  2397. 2.4.4.5.1\ \ If the sent and received unnumbered commands are the same, 
  2398. each STE shall send the UA\ response at the earliest possible opportunity. 
  2399. Each STE shall enter the indicated phase after receiving a UA\ response. 
  2400. .sp 9p
  2401. .RT
  2402. .LP
  2403. 2.4.4.5.2\ \ If the sent and received unnumbered commands are different, 
  2404. each STE shall enter the disconnected phase and issue a DM\ response at 
  2405. the earliest 
  2406. possible opportunity.
  2407. .sp 1P
  2408. .LP
  2409. 2.4.5
  2410.     \fIProcedures for information transfer\fR 
  2411. .sp 9p
  2412. .RT
  2413. .PP
  2414. The procedures which apply to the transmission of I frames in each direction 
  2415. during the information transfer phase are described below. 
  2416. .PP
  2417. In the following, \*Qnumber one higher\*U is in reference to a
  2418. continuously repeated sequence series, i.e.,\ 7 is 1\ higher than\ 6 and\ 0 is
  2419. 1\ higher than\ 7 for modulo 8\ series, and 127 is 1\ higher than\ 126 
  2420. and\ 0 is 
  2421. 1\ higher than\ 127 for modulo 128\ series.
  2422. .RT
  2423. .sp 1P
  2424. .LP
  2425. 2.4.5.1
  2426.     \fISending 1 frames\fR 
  2427. .sp 9p
  2428. .RT
  2429. .PP
  2430. When the STE has an I frame to transmit (i.e., an I frame not
  2431. already transmitted, or having to be retransmitted as described in \(sc\ 
  2432. 2.4.5.6 
  2433. below), it will transmit it with an\ N(S) equal to its current send state
  2434. variable V(S), and an N(R) equal to its current receive state variable\ V(R).
  2435. At the end of the transmission of the I\ frame, it will increment its send 
  2436. state variable\ V(S) by\ 1. 
  2437. .PP
  2438. If the Timer T1 is not running at the time of transmission of an
  2439. I\ frame, it will be started.
  2440. .PP
  2441. If the send state variable V(S) is equal to the last value of N(R)
  2442. received plus\ \fIk\fR (where\ \fIk\fR is the maximum number of outstanding 
  2443. I\ frames, see \(sc\ 2.4.8.6) the STE will not transmit any new I\ frames, 
  2444. but may retransmit an 
  2445. I\ frame as described in \(sc\ 2.4.5.6 or \(sc\ 2.4.5.9 below.
  2446. .PP
  2447. When the STE is in a busy condition, it may still transmit I frames
  2448. provided that the other STE is not busy. When in the frame rejection condition, 
  2449. the STE will stop transmitting I\ frames. 
  2450. .bp
  2451. .RT
  2452. .sp 2P
  2453. .LP
  2454. 2.4.5.2
  2455.     \fIReceiving an I frame\fR 
  2456. .sp 1P
  2457. .RT
  2458. .sp 1P
  2459. .LP
  2460. 2.4.5.2.1\ \ When the STE is not in a busy condition and receives a valid I
  2461. frame whose send sequence number\ N(S) is equal to the STE receive state
  2462. variable\ V(R), the STE will accept the information field of this frame,
  2463. increment by one its receive state variable\ V(R), and act as follows:
  2464. .sp 9p
  2465. .RT
  2466. .LP
  2467.     a)
  2468.     If the STE is still not in a busy condition:
  2469. .LP
  2470.     i)
  2471.     If an I frame is available for transmission by the
  2472. STE, it may act as in \(sc\ 2.4.5.1 above and acknowledge the received 
  2473. I\ frame by setting\ N(R) in the control field of the next transmitted 
  2474. I\ frame to the value of the STE receive state variable\ V(R). The STE 
  2475. may also acknowledge the 
  2476. received I\ frame by transmitting an\ RR with the\ N(R) equal to the value 
  2477. of the STE receive state variable\ V(R). 
  2478. .LP
  2479.     ii)
  2480.     If no I frame is available for transmission by the
  2481. STE, it will transmit an\ RR with the\ N(R) equal to the value of the STE 
  2482. receive state variable\ V(R). 
  2483. .LP
  2484.     b)
  2485.      If the STE is now in a busy condition, it will transmit an RNR frame 
  2486. with N(R) equal to the value of the STE receive state variable\ V(R) (see 
  2487. \(sc\ 2.4.5.8). 
  2488. .sp 1P
  2489. .LP
  2490. 2.4.5.2.2\ \ When the STE is in a busy condition, it may ignore the
  2491. information field contained in a received I\ frame.
  2492. .sp 9p
  2493. .RT
  2494. .sp 1P
  2495. .LP
  2496. 2.4.5.3
  2497.     \fIReception of invalid frames\fR 
  2498. .sp 9p
  2499. .RT
  2500. .PP
  2501. When the STE receives an invalid frame (see \(sc\ 2.3.5.3), this frame 
  2502. will be discarded. 
  2503. .RT
  2504. .sp 1P
  2505. .LP
  2506. 2.4.5.4
  2507.     \fIReception of out of sequence I frames\fR 
  2508. .sp 9p
  2509. .RT
  2510. .PP
  2511. When the STE receives a valid I frame whose send sequence number is incorrect, 
  2512. i.e.,\ not equal to the current STE receive state variable\ V(R), it will 
  2513. discard the information field of the frame and transmit a REJ frame with 
  2514. the\ N(R) set to one higher than the\ N(S) of the last correctly received 
  2515. I\ frame. The REJ frame will be a command frame with the P\ bit set to\ 1 if an
  2516. acknowledged transfer of the retransmission request is required; otherwise 
  2517. the REJ frame may be either a command or a response frame. The STE will 
  2518. then 
  2519. discard the information field of all I\ frames received until the expected
  2520. I\ frame is correctly received. When receiving the expected I\ frame, the STE
  2521. will then acknowledge the I\ frame as described in \(sc\ 2.4.5.2 above. 
  2522. The STE will use the N(R) and P\ bit information in the discard I\ frames, 
  2523. as described in 
  2524. \(sc\ 2.3.5.2 above.
  2525. .RT
  2526. .sp 1P
  2527. .LP
  2528. 2.4.5.5
  2529.     \fIReceiving acknowledgement\fR 
  2530. .sp 9p
  2531. .RT
  2532. .PP
  2533. When correctly receiving an I frame or a supervisory frame (RR, RNR or 
  2534. REJ), even in the busy condition except in the frame rejection condition, 
  2535. the STE will consider the N(R) contained in this frame as an acknowledgement
  2536. for all I\ frames it has transmitted with an\ N(S) up to and including the
  2537. received\ N(R)\ \(em\ 1. The STE will stop Timer\ T1 when it correctly 
  2538. receives an 
  2539. I\ frame or a supervisory frame with the\ N(R) higher than the last received\ 
  2540. N(R) (actually acknowledging some I\ frames), or an REJ frame with an N(R) 
  2541. equal to the last received\ N(R). 
  2542. .PP
  2543. If Timer T1 has been reset and if there are outstanding I frames still 
  2544. unacknowledged, Timer\ T1 will be restarted. If Timer\ T1 then runs out, 
  2545. the STE will follow the retransmission procedure (in \(sc\ 2.4.5.9 below) 
  2546. with respect to the unacknowledged I\ frames. 
  2547. .RT
  2548. .sp 1P
  2549. .LP
  2550. 2.4.5.6
  2551.     \fIReceiving an REJ frame\fR 
  2552. .sp 9p
  2553. .RT
  2554. .PP
  2555. When receiving an REJ frame, the STE will set its send state
  2556. variable V(S) to the\ N(R) received in the REJ control field. It will transmit 
  2557. the corresponding I\ frame as soon as it is available or retransmit it 
  2558. in 
  2559. accordance with the procedures described in \(sc\ 2.4.5.1 above. (Re)transmission 
  2560. will conform to the following procedure: 
  2561. .RT
  2562. .LP
  2563.     i)
  2564.     If the STE is transmitting a supervisory command or response
  2565. when it receives the REJ frame, it will complete that
  2566. transmission before commencing transmission of the requested
  2567. I\ frame.
  2568. .LP
  2569.     ii)
  2570.     If the STE is transmitting an unnumbered command or
  2571. response when it receives the REJ frame, it will ignore the
  2572. request for retransmission.
  2573. .LP
  2574.     iii)
  2575.     If the STE is transmitting an I frame when the REJ frame
  2576. is received, it may abort the I\ frame and commence
  2577. transmission of the requested I\ frame immediately after
  2578. abortion.
  2579. .LP
  2580.     iv)
  2581.     If the STE is not transmitting any frame when the REJ frame
  2582. is received, it will commence transmission of the requested
  2583. I\ frame immediately.
  2584. .bp
  2585. .PP
  2586. In all cases, if other unacknowledged I frames have already been transmitted 
  2587. following the one indicated in the REJ frame, then those I\ frames will 
  2588. be retransmitted by the STE following the retransmission of the requested 
  2589. I\ frame. Other I\ frames not yet transmitted may be transmitted following 
  2590. the 
  2591. retransmitted I\ frames.
  2592. .PP
  2593. If the REJ frame was received from the other STE as a command with the 
  2594. P\ bit set to\ 1, the STE will transmit an\ RR, RNR or REJ response with 
  2595. the F\ bit set to\ 1 before transmitting or retransmitting the corresponding 
  2596. I\ frame. 
  2597. .RT
  2598. .sp 1P
  2599. .LP
  2600. 2.4.5.7
  2601.     \fIReceiving an RNR frame\fR 
  2602. .sp 9p
  2603. .RT
  2604. .PP
  2605. After receiving an RNR frame whose N(R) acknowledges all frames
  2606. previously transmitted, the STE will stop Timer\ T1 and may then transmit an
  2607. I\ frame, with the P\ bit set to\ 0, whose send sequence number is equal to the
  2608. N(R) indicated in the RNR frame, restarting the Timer\ T1 as it does. After
  2609. receiving an RNR frame whose\ N(R) indicates a previously transmitted frame, 
  2610. the STE will not transmit or retransmit any I\ frame, Timer\ T1 being already 
  2611. running. In either case, if the Timer\ T1 runs out before receipt of a
  2612. busy clearance indication, the STE will follow the procedure described in
  2613. \(sc\ 2.4.5.9 below. In any case, the STE will not transmit any other I\ frames
  2614. before receiving an\ RR or REJ frame or before the completion of a link
  2615. resetting procedure.
  2616. .RT
  2617. .sp 1P
  2618. .LP
  2619. 2.4.5.8
  2620.     \fISTE busy condition\fR 
  2621. .sp 9p
  2622. .RT
  2623. .PP
  2624. When the STE enters a busy condition, it will transmit an RNR frame at 
  2625. the earliest opportunity. The RNR frame will be a command frame with the 
  2626. P\ bit set to\ 1 if an acknowledged transfer of the busy condition indication 
  2627. is required; otherwise the RNR frame may be either a command or response 
  2628. frame. 
  2629. While in the busy condition, the STE will accept and process supervisory
  2630. frames, will accept and process the contents of the N(R) fields of I\ frames,
  2631. and will return an RNR response with the F\ bit set to\ 1 if it receives a
  2632. supervisory command or I\ command frame with the P\ bit set to\ 1. To clear the
  2633. busy condition, the STE will transmit either an REJ frame or an RR\ frame,
  2634. with\ N(R) set to the current receive state variable\ V(R), depending on 
  2635. whether or not it discarded information fields of correctly received I\ 
  2636. frames. The REJ frame or the RR\ frame will be a command frame with the 
  2637. P\ bit set to\ 1 if an 
  2638. acknowledged transfer of the busy\(hyto\(hynon\(hybusy transition is required, 
  2639. otherwise the REJ frame or the RR\ frame may be either a command or a response 
  2640. frame.
  2641. .RT
  2642. .sp 1P
  2643. .LP
  2644. 2.4.5.9
  2645.     \fIWaiting acknowledgement\fR 
  2646. .sp 9p
  2647. .RT
  2648. .PP
  2649. If Timer T1 runs out waiting for the acknowledgement from the other STE 
  2650. for an I\ frame transmitted, the STE will enter the timer recovery 
  2651. condition, add one to its transmission attempt variable and set an internal
  2652. variable\ \*Qx\*U to the current value of its send state variable\ V(S). 
  2653. The STE will then restart Timer\ T1, set its send state variable to the 
  2654. last value of\ N(R) 
  2655. received from the other STE and retransmit the corresponding I\ frame with 
  2656. the P\ bit set to\ 1, or transmit an appropriate supervisory command frame 
  2657. (RR,\ RNR or REJ) with the P\ bit set to\ 1. 
  2658. .PP
  2659. The timer recovery condition is cleared when the STE receives a valid supervisory 
  2660. frame with the F\ bit set to\ 1. 
  2661. .PP
  2662. If, while in the timer recovery condition, the STE correctly receives a 
  2663. supervisory frame with the F\ bit set to\ 1 and with the\ N(R) within the 
  2664. range from its current send state variable\ V(S) to\ \fIx\fR included, 
  2665. it will clear the 
  2666. timer recovery condition (including stopping Timer\ T1) and set its send 
  2667. state variable\ V(S) to the value of the received\ N(R), and may then resume 
  2668. with 
  2669. I\ frame transmission or retransmission, as appropriate.
  2670. .PP
  2671. If, while in the timer recovery condition, the STE correctly receives an 
  2672. I\ frame or a supervisory frame with the P/F\ bit set to\ 0 and with a 
  2673. valid\ N(R) (see \(sc\ 2.3.4.9) within the range from its current send state
  2674. variable\ V(S) to \fIx\fR \ included, it will not clear the timer recovery 
  2675. condition. The value of the received\ N(R) may be used to update the send 
  2676. state 
  2677. variable\ V(S). However, the STE may decide to keep the last transmitted 
  2678. I\ frame in store (even if it is acknowledged) in order to be able to retransmit 
  2679. it when the P\ bit set to\ 1 when Timer\ T1 runs out at a later time. 
  2680. .PP
  2681. If Timer T1 runs out in the timer recovery condition, the STE will add 
  2682. one to its transmission attempt variable, restart Timer\ T1, and either 
  2683. retransmit the I\ frame sent with the P\ bit set to\ 1 or transmit an appropriate 
  2684. supervisory command with the P\ bit set to\ 1. 
  2685. .PP
  2686. If the transmission attempt variable is equal to N2, the STE will
  2687. initiate a link resetting procedure as described in
  2688. \(sc\ 2.4.7.2 below. N2\ is a system parameter (see \(sc\ 2.4.8.4 below).
  2689. .bp
  2690. .RT
  2691. .sp 2P
  2692. .LP
  2693. 2.4.6
  2694.     \fIConditions for link resetting or link reinitialization (link\fR 
  2695. \fIset\(hyup)\fR 
  2696. .sp 1P
  2697. .RT
  2698. .PP
  2699. 2.4.6.1
  2700. When the STE receives, during the information transfer phase, a frame which 
  2701. is not invalid (see \(sc\ 2.3.5.3) with one of the conditions listed in 
  2702. \(sc\ 2.3.4.9 above, the STE will request the other STE to initiate a link 
  2703. resetting procedure by transmitting an FRMR response as described in
  2704. \(sc\ 2.4.7.3.
  2705. .sp 9p
  2706. .RT
  2707. .PP
  2708. 2.4.6.2
  2709. When the STE receives, during the information transfer phase, an FRMR response 
  2710. from the other STE, the STE will initiate the link resetting 
  2711. procedures as described in \(sc\ 2.4.7.2.
  2712. .sp 2P
  2713. .LP
  2714. 2.4.7
  2715.     \fIProcedure for link resetting\fR 
  2716. .sp 1P
  2717. .RT
  2718. .PP
  2719. 2.4.7.1
  2720. The link resetting procedure is used to initialize both
  2721. directions of information transfer according to the procedure described 
  2722. below. The link resetting procedure only applies during the information 
  2723. transfer 
  2724. phase.
  2725. .sp 9p
  2726. .RT
  2727. .PP
  2728. 2.4.7.2
  2729. The link resetting procedure indicates a clearance of the busy
  2730. condition, if present.
  2731. .PP
  2732. The STE will initiate a link resetting by transmitting an
  2733. SABM/SABME command to the other STE and starting its Timer\ T1 (see \(sc\ 
  2734. 2.4.8.1 
  2735. below). Upon reception of a UA\ response from the other STE, the STE will 
  2736. reset its send and receive state variables\ V(S) and V(R) to zero, will 
  2737. stop its 
  2738. Timer\ T1, and will remain in the information transfer phase. Upon reception 
  2739. of a DM\ response from the DTE as a denial to the link resetting request, 
  2740. the STE will stop its Timer\ T1 and will enter the disconnected phase. 
  2741. .PP
  2742. If upon receipt of the SABM/SABME command correctly, the STE
  2743. determines that it can continue in the information transfer phase, it will
  2744. return a UA\ response, will reset its send and receive state variables\ V(S)
  2745. and\ V(R) to zero, and will remain in the information transfer phase. If, 
  2746. upon receipt of the SABM/SABME command correctly, the STE determines that 
  2747. it cannot remain in the information transfer phase, it will return a DM\ 
  2748. response as a 
  2749. denial to the resetting request and will enter the disconnected phase.
  2750. .PP
  2751. The STE, having sent an SABM/SABME command, will ignore and discard
  2752. any frames except an SABM/SABME or DISC command, UA\ or DM\ response received.
  2753. The receipt of an SABM/SABME or DISC command from the other STE will result 
  2754. in a collision situation that is resolved per \(sc\ 2.4.4.5 above. Frames 
  2755. other than the UA or DM\ response sent in response to a received SABM/SABME 
  2756. or DISC command will be sent only after the link is reset and if no outstanding 
  2757. SABM/SABME 
  2758. command exists.
  2759. .PP
  2760. After the STE sends the SABM/SABME command, if a UA or DM response is not 
  2761. received correctly, Timer\ T1 will run out. The STE will then resend the 
  2762. SABM/SABME command and will restart Timer\ T1. After N2\ attempts to reset the
  2763. link, the STE will initiate appropriate higher layer recovery action and 
  2764. will enter the disconnected phase. The value of\ N2 is defined in \(sc\ 
  2765. 2.4.8.4 
  2766. below.
  2767. .RT
  2768. .PP
  2769. 2.4.7.3
  2770. The STE may ask the other STE to reset the link by transmitting an FRMR 
  2771. response (see \(sc\ 2.4.6.1 above). 
  2772. .sp 9p
  2773. .RT
  2774. .PP
  2775. After transmitting an FRMR response, the STE will enter the frame rejection 
  2776. condition. The frame rejection condition is cleared when the STE 
  2777. receives or transmits an SABM/SABME or DISC command. Any other frame received 
  2778. while in the frame rejection condition will cause the STE to retransmit 
  2779. the 
  2780. FRMR response with the same information field as originally transmitted.
  2781. .PP
  2782. The STE may start Timer T1 on transmission of the FRMR response. If
  2783. Timer\ T1 runs out before the frame rejection condition is cleared the 
  2784. STE may retransmit the FRMR response, and restart Timer\ T1. After N2\ 
  2785. attempts to get 
  2786. the other STE to reset the link, the STE may reset the link itself as described 
  2787. in \(sc\ 2.4.7.2 above. The value of\ N2 is defined in \(sc\ 2.4.8.4 below. 
  2788. .PP
  2789. In the frame rejection condition, I frames and supervisory frames will 
  2790. not be transmitted. Also, received I\ frames and supervisory frames will 
  2791. be 
  2792. discarded by the STE except for the observance of a P\ bit set to\ 1. When an
  2793. additional FRMR response must be transmitted as a result of the receipt of a
  2794. P\ bit set to\ 1 while Timer\ T1 is running, Timer\ T1 will continue to run.
  2795. .PP
  2796. Upon reception of a FRMR response (even during a frame rejection
  2797. condition), the STE will initiate a resetting procedure by transmitting a
  2798. SABM/SABME command as described in \(sc\ 2.4.7.2 above.
  2799. .bp
  2800. .RT
  2801. .sp 1P
  2802. .LP
  2803. 2.4.8
  2804.     \fIList of system parameters\fR 
  2805. .sp 9p
  2806. .RT
  2807. .PP
  2808. The system parameters are as follows:
  2809. .RT
  2810. .sp 1P
  2811. .LP
  2812. 2.4.8.1
  2813.     \fITimer T1\fR 
  2814. .sp 9p
  2815. .RT
  2816. .PP
  2817. The period of Timer T1, at the end of which transmission of a frame may 
  2818. be initiated, is a system parameter agreed for a period of time between 
  2819. the Administrations. 
  2820. .PP
  2821. The period of Timer T1 will take into account whether the timer is
  2822. started at the beginning or end of transmission of the frame in the
  2823. STE.
  2824. .PP
  2825. The proper operation of the procedure requires that the transmitter's Timer\ 
  2826. T1 be greater than the maximum time between transmission of a frame 
  2827. (SABM/SABME, DISC,\ I for supervisory command, or DM or FRMR response) 
  2828. and the reception of the corresponding frame) returned as an answer to 
  2829. that frame (UA, DM or acknowledging frame). Therefore, the receiver STE 
  2830. should not delay the 
  2831. response or acknowledging frame returned to one of the above frames by more
  2832. than a value\ T2, where\ T2 is a system parameter (see \(sc\ 2.4.8.2).
  2833. .PP
  2834. The STE will not delay the response or acknowledging frame returned to 
  2835. one of the above frames by more than a period\ T2. 
  2836. .RT
  2837. .sp 1P
  2838. .LP
  2839. 2.4.8.2
  2840.     \fIParameter T2\fR 
  2841. .sp 9p
  2842. .RT
  2843. .PP
  2844. The period of parameter T2 shall indicate the amount of time
  2845. available at the STE before the acknowledging frame must be initiated in 
  2846. order to ensure its receipt by the other STE prior to Timer\ T1 running 
  2847. out at the STE (parameter\ T2\ <\ Timer\ T1). 
  2848. .RT
  2849. .sp 1P
  2850. .LP
  2851. 2.4.8.3
  2852.     \fITimer T3\fR 
  2853. .sp 9p
  2854. .RT
  2855. .PP
  2856. The STE shall support a Timer T3 system parameter, the value of
  2857. which shall be made known to both STEs.
  2858. .PP
  2859. The period of Timer T3, at the end of which an indication of an
  2860. observed excessively long idle channel state condition is passed to the 
  2861. packet layer or the MLP, shall be sufficiently greater than the period 
  2862. of the Timer\ T1 (i.e.,\ T3\ >\ T1) so that the expiration of\ T3 provides 
  2863. the desired level of 
  2864. assurance that the link channel is in a non\(hyactive, non\(hyoperational 
  2865. state, and is in need of link set up before normal link operation can resume. 
  2866. .RT
  2867. .sp 1P
  2868. .LP
  2869. 2.4.8.4
  2870.     \fIMaximum number of attempts to complete a transmission, N2\fR 
  2871. .sp 9p
  2872. .RT
  2873. .PP
  2874. The value of the maximum number N2 of transmission and
  2875. retransmissions of a frame following the running out of Timer\ T1 is a system
  2876. parameter agreed for a period of time between Administrations. The value 
  2877. of\ N2 can be different in STE\(hyX and STE\(hyY. 
  2878. .RT
  2879. .sp 1P
  2880. .LP
  2881. 2.4.8.5
  2882.     \fIMaximum number of bits in an I frame, N1\fR 
  2883. .sp 9p
  2884. .RT
  2885. .PP
  2886. The maximum number of bits in an I frame (excluding flags and 0 bits inserted 
  2887. for transparency) is a system parameter which depends upon the maximum 
  2888. length of the information fields transferred across the X/Y\ interface. 
  2889. .PP
  2890. \fINote\fR \ \(em\ When multilink procedures are used, N1 shall allow for the
  2891. multilink control field (MLC). See \(sc\ 2.5.2 below. Appendix\ II of
  2892. Recommendation\ X.25 provides additional information on\ N1. The utility field
  2893. has to be added.
  2894. .RT
  2895. .sp 1P
  2896. .LP
  2897. 2.4.8.6
  2898.     \fIMaximum number of outstanding I frames, k\fR 
  2899. .sp 9p
  2900. .RT
  2901. .PP
  2902. The maximum number (k) of sequentially numbered I frames that the STE may 
  2903. have outstanding (i.e.,\ unacknowledged) at any given time is a system 
  2904. parameter which can never exceed\ 7/127 (modulo\ 8/modulo\ 128). It shall 
  2905. be 
  2906. agreed for a period of time between Administrations and shall have the same
  2907. value for both the STEs.
  2908. .RT
  2909. .sp 1P
  2910. .LP
  2911. 2.5
  2912.     \fIMultilink procedures (MLP)\fR 
  2913. .sp 9p
  2914. .RT
  2915. .PP
  2916. The multilink procedure (MLP) exists as an added upper sublayer of the 
  2917. data link layer, operating between the packet layer and a multiplicity 
  2918. of single data link protocol functions (SLPs) in the data link layer (see 
  2919. Figure\ 2/X.75).
  2920. .bp
  2921. .RT
  2922. .LP
  2923. .rs
  2924. .sp 26P
  2925. .ad r
  2926. \fBFigure 2/X.75, p.\fR 
  2927. .sp 1P
  2928. .RT
  2929. .ad b
  2930. .RT
  2931. .PP
  2932. A multilink procedure (MLP) must perform the functions of
  2933. distributing across the available SLPs, packets which are to be transmitted 
  2934. to the remote STE and of resequencing packets received from the remote 
  2935. STE for 
  2936. delivery to the packet layer.
  2937. .PP
  2938. \fINote\ 1\fR \ \(em\ In \(sc\ 2.5.4.4 (MT1 expiry) and \(sc\ 2.5.4.5 (retransmission), 
  2939. other mechanisms can be envisaged to achieve the same functions. 
  2940. .PP
  2941. \fINote\ 2\fR \ \(em\ In \(sc\ 2.5.5.4 (MN1), \(sc\ 2.5.5.1 (MT1) and \(sc\ 
  2942. 2.5.5.2 (MT2) 
  2943. other mechanisms can be envisaged to achieve the same functions.
  2944. .RT
  2945. .sp 1P
  2946. .LP
  2947. 2.5.1
  2948.     \fIField of application\fR 
  2949. .sp 9p
  2950. .RT
  2951. .PP
  2952. The optional multilink procedure (MLP) described below is used for data 
  2953. interchange over one or more single link procedures (SLPs), each 
  2954. conforming to the description in \(sc\(sc\ 2.2, 2.3 and\ 2.4, in parallel 
  2955. between two STEs. The multilink procedure provides the following general 
  2956. features:
  2957. .RT
  2958. .LP
  2959.     a)
  2960.     achieve economy and reliability of service by providing
  2961. multiple SLPs between two STEs;
  2962. .LP
  2963.     b)
  2964.     permit addition and deletion of SLPs without interrupting
  2965. the service provided by the multiple SLPs;
  2966. .LP
  2967.     c)
  2968.     optimize bandwidth utilization of a group of SLPs through
  2969. load sharing;
  2970. .LP
  2971.     d)
  2972.     achieve graceful degradation of service when an SLP(s)
  2973. fails;
  2974. .LP
  2975.     e)
  2976.      provide each multiple SLP group with a single logical data link layer 
  2977. appearance to the packet layer, and 
  2978. .LP
  2979.     f
  2980. )
  2981.     provide sequencing of the received packets prior to
  2982. delivering them to the packet layer.
  2983. .bp
  2984. .sp 1P
  2985. .LP
  2986. 2.5.2
  2987.     \fIMultilink frame structure\fR 
  2988. .sp 9p
  2989. .RT
  2990. .PP
  2991. All information transfers over an SLP are in multilink frames
  2992. conforming to one of the formats shown in Table\ 9/X.75.
  2993. .RT
  2994. .LP
  2995. .rs
  2996. .sp 14P
  2997. .ad r
  2998. \fBTable 9/X.75 (\*`a traiter comme figure MEP), p.\fR 
  2999. .sp 1P
  3000. .RT
  3001. .ad b
  3002. .RT
  3003. .sp 1P
  3004. .LP
  3005. 2.5.2.1
  3006.     \fIMultilink control field\fR 
  3007. .sp 9p
  3008. .RT
  3009. .PP
  3010. The multilink control field (MLC) consists of two octets and its
  3011. contents are described in \(sc\ 2.5.3.
  3012. .RT
  3013. .sp 1P
  3014. .LP
  3015. 2.5.2.2
  3016.     \fIMultilink information field\fR 
  3017. .sp 9p
  3018. .RT
  3019. .PP
  3020. The information field of a multilink frame, when present, follows the MLC. 
  3021. See \(sc\ 2.5.3.2.3, \(sc\ 2.5.3.2.4 and \(sc\ 4 for the various codings 
  3022. and 
  3023. grouping of bits in the multilink information field.
  3024. .RT
  3025. .sp 2P
  3026. .LP
  3027. 2.5.3
  3028.     \fIMultilink control field format and parameters\fR 
  3029. .sp 1P
  3030. .RT
  3031. .sp 1P
  3032. .LP
  3033. 2.5.3.1
  3034.     \fIMultilink control field format\fR 
  3035. .sp 9p
  3036. .RT
  3037. .PP
  3038. The relationship shown in Table 10/X.75 exists between the order of bits 
  3039. delivered to/received from an SLP and the coding of the fields in the 
  3040. multilink control field.
  3041. .RT
  3042. .sp 1P
  3043. .LP
  3044. 2.5.3.2
  3045.     \fIMultilink control field parameters\fR 
  3046. .sp 9p
  3047. .RT
  3048. .PP
  3049. The various paramaters associated with the multilink control field format 
  3050. are described below. See Table\ 10/X.75 and Figure\ 2/X.75. 
  3051. .RT
  3052. .sp 1P
  3053. .LP
  3054. 2.5.3.2.1
  3055.     \fIVoid sequencing bit (V)\fR 
  3056. .sp 9p
  3057. .RT
  3058. .PP
  3059. The void sequencing bit (V) indicates if a received multilink frame shall 
  3060. be subjected to sequencing constraints. V set to\ 1 means sequencing shall 
  3061. not be required. V set to\ 0 means sequencing shall be required. 
  3062. .PP
  3063. \fINote\fR \ \(em\ For the purpose of this Recommendation, this bit shall 
  3064. be set to\ 0. 
  3065. .RT
  3066. .sp 1P
  3067. .LP
  3068. 2.5.3.2.2
  3069.     \fISequence check option bit (S)\fR 
  3070. .sp 9p
  3071. .RT
  3072. .PP
  3073. The sequence check option bit (S) is only significant when V is set to 
  3074. 1 (indicating that sequencing of received multilink frames shall not be 
  3075. required). S set to\ 1 shall mean no MN(S) number has been assigned. S 
  3076. set to\ 0 shall mean an MN(S) number has been assigned, so that although 
  3077. sequencing shall not be required, a duplicate multilink frame check may 
  3078. be made, as well as a 
  3079. missing multilink frame identified.
  3080. .PP
  3081. \fINote\fR \ \(em\ For the purpose of this Recommendation, this bit shall 
  3082. be set to 0. 
  3083. .bp
  3084. .RT
  3085. .LP
  3086. .rs
  3087. .sp 22P
  3088. .ad r
  3089. \fBTableau 10/X.75 \ \ 
  3090. (\*`a traiter comme figure MEP), p.25\fR 
  3091. .sp 1P
  3092. .RT
  3093. .ad b
  3094. .RT
  3095. .sp 1P
  3096. .LP
  3097. 2.5.3.2.3
  3098.     \fIMLP reset request bit (R)\fR 
  3099. .sp 9p
  3100. .RT
  3101. .PP
  3102. The MLP reset request bit (R) is used to request a multilink reset (see 
  3103. \(sc\ 2.5.4.2). R set to\ 0 is used in normal communication; i.e., no request 
  3104. for a multilink reset. R set to\ 1 is used by the STE MLP to request the 
  3105. reset of the remote MLP state variables. In this R\ =\ 1 case, the multilink 
  3106. information
  3107. field does not contain packet layer information, but may contain an optional
  3108. 8\(hybit cause field that incorporates the reason for the reset.
  3109. .PP
  3110. \fINote\fR \ \(em\ The encoding of the cause field is a subject for further
  3111. study.
  3112. .RT
  3113. .sp 1P
  3114. .LP
  3115. 2.5.3.2.4
  3116.     \fIMLP reset confirmation bit (C)\fR 
  3117. .sp 9p
  3118. .RT
  3119. .PP
  3120. The MLP reset confirmation bit (C) is used in reply to an R bit set to 
  3121. 1 (see \(sc\ 2.5.3.2.3) to confirm the resetting of the multilink state 
  3122. variables (see \(sc\ 2.5.4.2). C set to\ 0 is used in normal communication; 
  3123. i.e., no multilink reset request has been activated. C set to\ 1 is used 
  3124. by the STE MLP in reply to a multilink frame from the remote STE with R 
  3125. set to\ 1, and 
  3126. indicates
  3127. that the MLP state variable reset process has been completed. In this C\ =\ 1
  3128. case, the multilink frame is used without an information field.
  3129. .RT
  3130. .sp 1P
  3131. .LP
  3132. 2.5.3.2.5
  3133.     \fIMultilink send state variable MV(S)\fR 
  3134. .sp 9p
  3135. .RT
  3136. .PP
  3137. The multilink send state variable MV(S) denotes the sequence number of 
  3138. the next in\(hysequence multilink frame to be assigned to an SLP. The variable 
  3139. can take on the value\ 0 through\ 4095 (modulus\ 4096). The value of MV(S) 
  3140. is 
  3141. incremented by\ 1 with each successive multilink frame assignment.
  3142. .bp
  3143. .RT
  3144. .sp 1P
  3145. .LP
  3146. 2.5.3.2.6
  3147.     \fIMultilink sequence number MN(S)\fR 
  3148. .sp 9p
  3149. .RT
  3150. .PP
  3151. Multilink frames contain the multilink sequence number MN(S). Prior to 
  3152. the assignment of an in\(hysequence multilink frame, the value of MN(S) 
  3153. is 
  3154. updated to equal the value of the multilink send state variable MV(S). The
  3155. multilink sequence number is used to resequence and to detect missing and
  3156. duplicate multilink frames at the receiver before the contents of a multilink 
  3157. frame information field is delivered to the packet layer. 
  3158. .RT
  3159. .LP
  3160. .rs
  3161. .sp 31P
  3162. .ad r
  3163. \fBFigure 3/X.75, p. 
  3164. .sp 1P
  3165. .RT
  3166. .ad b
  3167. .RT
  3168. .sp 1P
  3169. .LP
  3170. 2.5.3.2.7
  3171.     \fITransmitted multilink acknowledged state variable MV(T)\fR 
  3172. .sp 9p
  3173. .RT
  3174. .PP
  3175. MV(T) is the state variable at the transmitting STE denoting the
  3176. oldest multilink frame which is awaiting an indication that a local SLP has
  3177. received an acknowledgement from its remote SLP. This variable MV(T) can 
  3178. take on the value\ 0 through\ 4095 (modulus\ 4096). Some multilink frames 
  3179. with sequence numbers higher than MV(T) may already have been acknowledged. 
  3180. .RT
  3181. .sp 1P
  3182. .LP
  3183. 2.5.3.2.8
  3184.     \fIMultilink receive state variable MV(R)\fR 
  3185. .sp 9p
  3186. .RT
  3187. .PP
  3188. The multilink receive state variable MV(R) denotes the sequence
  3189. number at the receiving STE of the next in\(hysequence multilink frame to be
  3190. received and delivered to the packet layer. This variable MV(R) can take 
  3191. on the value\ 0 through\ 4095 (modulus\ 4096). The value of MV(R) is updated 
  3192. as described in \(sc\ 2.5.4.4 below. Multilink frames with higher sequence 
  3193. numbers in the MLP 
  3194. receive window may already have been received.
  3195. .bp
  3196. .RT
  3197. .sp 1P
  3198. .LP
  3199. 2.5.3.2.9
  3200.     \fIMultilink window size MW\fR 
  3201. .sp 9p
  3202. .RT
  3203. .PP
  3204. MW is the maximum number of sequentially numbered multilink frames that 
  3205. the STE may transfer to its SLPs beyond the lowest numbered multilink 
  3206. frame which has not as yet been acknowledged. MW is a system parameter which
  3207. can never exceed (4095\ \(em\ MX).
  3208. .PP
  3209. The value of MW shall be agreed between
  3210. Administrations and shall have the same value for both STEs for a given
  3211. direction of information transfer.
  3212. .PP
  3213. \fINote\fR \ \(em\ Factors which will affect the value of parameter MW 
  3214. include, but are not limited to single link transmission and propagation 
  3215. delays, the 
  3216. number of links, the range of multilink frame lengths, and SLP parameters\ 
  3217. N2, T1 and\ \fIk\fR . 
  3218. .PP
  3219. The MLP transmit window contains the sequence numbers MV(T) to
  3220. [MV(T)\ +\ MW\ \(em\ 1] inclusive.
  3221. .PP
  3222. The MLP receive window contains the sequence numbers MV(R) to
  3223. [MV(R)\ +\ MW\(em1] inclusive. Any multilink frame received within this 
  3224. window shall be delivered to the packet layer when its MN(S) is the same 
  3225. as MV(R). 
  3226. .RT
  3227. .sp 1P
  3228. .LP
  3229. 2.5.3.2.10
  3230.     \fIReceive MLP window guard region MX\fR 
  3231. .sp 9p
  3232. .RT
  3233. .PP
  3234. MX is a system parameter which defines a guard region of multilink sequence 
  3235. numbers of fixed size beginning at [MV(R)\ +\ MW]. The range of MX shall 
  3236. be large enough for the receiving MLP to recognize the highest MN(S) outside 
  3237. of its receive window that it may legitimately receive after a multilink 
  3238. frame 
  3239. loss has occurred.
  3240. .PP
  3241. A multilink frame with sequence number MN(S) = Y received in this
  3242. guard region indicates that those missing multilink frame(s) in the range\ 
  3243. MV(R) to [Y\ \(em\ MW] has(have) been lost. MV(R) is then updated to [Y\ 
  3244. \(em\ MW\ +\ 1]. 
  3245. .PP
  3246. \fINote\fR \ \(em\ A number of methods may be selected in calculating a value
  3247. for the guard region MX:
  3248. .RT
  3249. .LP
  3250.     a)
  3251.     In a system where the transmission MLP assigns \fIh\fR\d\fIi\fR\u
  3252. in\(hysequence contiguous multilink frames at a time to the \fIi\fR
  3253. \u\fIh\fR\d\ SLP,
  3254. MX should be greater than or equal to the sum of
  3255. [\fIh\fR\d\fIi\fR\u\ +\ 1\ \(em\ \fIh\fR\dm\\di\\dn\u],
  3256. where \fIh\fR\dm\\di\\dn\uequals the smallest \fIh\fR\d\fIi\fR\uencountered.
  3257. Where there are \fIL\fR \ SLPs in the multilink group, MX should be
  3258. greater than or equal to:
  3259. \v'6p'
  3260. .sp 1P
  3261. .ce 1000
  3262. @ pile {\fIL\fR above sum above \fIi\fR =1
  3263. } @ \fIh\fR\d\fIi\fR\u+ 1 \(em \fIh\fR\dm\\di\\dn\u; \fIor\fR 
  3264. .ce 0
  3265. .sp 1P
  3266. .LP
  3267. .sp 1
  3268. .LP
  3269.     b)
  3270.      In a system where the transmitting MLP assigns on a rotation basis \fIh\fR 
  3271. in\(hysequence, contiguous multilink frames at a time to 
  3272. each SLP, MX at the receiving MLP should be greater than or
  3273. equal to [\fIh\fR (\fIL\fR \ \(em\ 1)\ +\ 1], where \fIL\fR is the number 
  3274. of SLPs in 
  3275. the multilink group; or
  3276. .LP
  3277.     c)
  3278.     MX should be no larger than MW.
  3279. .PP
  3280. Additional methods of selecting MX values are for further
  3281. study.
  3282. .sp 1P
  3283. .LP
  3284. 2.5.4
  3285.     \fIDescription of multilink procedure (MLP)\fR 
  3286. .sp 9p
  3287. .RT
  3288. .PP
  3289. The procedure below is presented from the perspective of the
  3290. transmitter and receiver of multilink frames.
  3291. .PP
  3292. The arithmetic is performed modulo 4096.
  3293. .RT
  3294. .sp 1P
  3295. .LP
  3296. 2.5.4.1
  3297.     \fIInitialization\fR 
  3298. .sp 9p
  3299. .RT
  3300. .PP
  3301. The STE will perform an MLP initialization by first resetting
  3302. MV(S), MV(T), and MV(R) to zero and then initializing each of its SLPs. Upon
  3303. successful initialization of at least one of the SLPs, the STE shall perform
  3304. the multilink resetting procedure as described in \(sc\ 2.5.4.2. An SLP
  3305. initialization is performed according to \(sc\ 2.4.4.1 of this Recommendation.
  3306. .PP
  3307. \fINote\fR \ \(em\ An SLP that cannot be initialized should be declared 
  3308. out of service and appropriate recovery action should be taken. 
  3309. .bp
  3310. .RT
  3311. .sp 1P
  3312. .LP
  3313. 2.5.4.2
  3314.     \fIMultilink resetting procedure\fR 
  3315. .sp 9p
  3316. .RT
  3317. .PP
  3318. The multilink resetting procedure provides the mechanism for
  3319. synchronizing the sending and receiving MLPs in both STEs when deemed
  3320. necessary by either STE. Exact cases when a MLP reset procedure will be
  3321. invoked are for further study. Following
  3322. a successful multilink resetting procedure, the multilink sequence numbering 
  3323. in each direction begins with the value\ 0. 
  3324. .PP
  3325. Appendix I provides examples for the multilink resetting procedures
  3326. when initiated by either a single STE or by both STEs simultaneously.
  3327. .PP
  3328. A multilink frame with R = 1 is used to request multilink reset, and a 
  3329. multilink frame with C\ =\ 1 confirms that the multilink reset process 
  3330. has been completed. An MLP resets MV(S) and MV(T) to zero on transfer of 
  3331. a multilink 
  3332. frame with R\ =\ 1 and resets the MV(R) to zero on receipt of a multilink 
  3333. frame with\ R\ =\ 1. 
  3334. .PP
  3335. When the MLP initiates the resetting procedure, it removes all of the unacknowledged 
  3336. multilink frames that are held in that MLP and its associated 
  3337. SLPs, and retains control of those frames. Hereafter, the initiating MLP 
  3338. does not transmit a multilink frame with R\ =\ C\ =\ 0 until the reset 
  3339. process is 
  3340. completed. (One method to remove multilink frames in the SLP is to disconnect 
  3341. the link of that SLP.) The initiating MLP then resets its multilink send 
  3342. state variable MV(S) and its transmitted multilink frame acknowledged state 
  3343. variable MV(T) to zero. The initiating MLP then transmits a multilink frame 
  3344. with R\ =\ 1 as a reset request on one of its SLPs and starts Timer\ MT3. 
  3345. The value of the 
  3346. MN(S) field in the R\ =\ 1 frame may be any value, since when R\ =\ 1 the MN(S)
  3347. field is ignored by the receiving MLP. The initiating MLP continues to 
  3348. receive and process multilink frames from the remote MLP, in accordance 
  3349. with the 
  3350. procedures as described in \(sc\ 2.5.4.4 until it receives a multilink 
  3351. frame with R\ =\ 1 from the remote MLP. 
  3352. .PP
  3353. An MLP which has received a multilink frame with R = 1 (reset request) 
  3354. in the normal communication status from an initiating MLP starts the operation 
  3355. as described above; the MLP should receive no multilink frames with R\ 
  3356. =\ C\ =\ 0 until the reset process is completed. Any such frame received 
  3357. is discarded. 
  3358. When the MLP has already initiated its own multilink resetting procedure and
  3359. has transferred the multilink frame with R\ =\ 1 to one of its SLPs for
  3360. transmission, that MLP does not repeat the above operation upon receipt of a
  3361. multilink frame with R\ =\ 1 from the remote MLP.
  3362. .PP
  3363. Receipt of a frame with R = 1 (reset request) causes the receiving MLP 
  3364. to deliver to the packet layer those packets already received and to identify 
  3365. those multilink frames transmitted but unacknowledged. The packet layer 
  3366. may be informed of the packet loss at the original value of MV(R) and at 
  3367. any 
  3368. subsequent value(s) of MV(R) for which there has been no multilink frame
  3369. received up to and including the highest numbered multilink frame received.
  3370. The receiving MLP then resets its multilink receive state variable MV(R) to
  3371. zero.
  3372. .PP
  3373. After an MLP transmits a multilink frame with R = 1 on one of its
  3374. SLPs, it shall receive confirmation of successful transfer from that SLP 
  3375. as one of the conditions before transmitting a multilink frame with C\ 
  3376. =\ 1; 
  3377. when the initiating MLP then received a multilink frame with R\ =\ 1,
  3378. and has completed the variable resetting operation above, the initiating MLP
  3379. transmits a multilink frame with C\ =\ 1 (reset confirmation) to the remote 
  3380. MLP. When an MLP has 
  3381. .RT
  3382. .LP
  3383.     1)
  3384.     received a multilink frame with R = 1,
  3385. .LP
  3386.     2)
  3387.     sent a multilink frame with R = 1 on one of its SLPs, and
  3388. .LP
  3389.     3)
  3390.     completed the variable resetting operation above,
  3391. .LP
  3392. that MLP then transmits a multilink frame with C = 1 (reset confirmation) to
  3393. the initiating MLP as soon as possible, given that confirmation of the 
  3394. transfer of the R\ =\ 1 multilink frame has been received from that SLP. 
  3395. The C\ =\ 1 
  3396. multilink frame is a reply to the multilink frame with R\ =\ 1. The value 
  3397. of the MN(S) field in the above C\ =\ 1 frame may be any value, since with 
  3398. C\ =\ 1 the 
  3399. MN(S) field is ignored by the receiving MLP. The multilink sequence number
  3400. MN(S) received in each direction following multilink reset will begin with 
  3401. the value zero. 
  3402. .PP
  3403. When an MLP uses the same or only one SLP to transmit the
  3404. multilink frame with C\ =\ 1, the MLP can transmit the multilink frame 
  3405. with C\ =\ 1 immediately after the multilink frame with R\ =\ 1 without 
  3406. waiting for SLP 
  3407. indication of transfer completion. An MLP may use two different SLPs as long
  3408. as one is used for transmitting the multilink frame with R\ =\ 1 and the 
  3409. other is used for transmitting the multilink frame with C\ =\ 1 following 
  3410. receipt of the SLP indication of successful transmission of the R\ =\ 1 
  3411. multilink frame. A 
  3412. multilink frame with R\ =\ C\ =\ 1 is never used and will be discarded if
  3413. received.
  3414. .bp
  3415. .PP
  3416. When an MLP receives the multilink frame with C = 1, the MLP stops its 
  3417. Timer MT3. The successful transmission of the multilink frame with C\ =\ 
  3418. 1 to the remote MLP and the reception of a multilink frame with C\ =\ 1 
  3419. from the remote 
  3420. MLP completes the resetting procedure. The first multilink frame transmitted
  3421. with R\ =\ C\ =\ 0 shall have a multilink sequence number MN(S) value of 
  3422. zero. (The originating MLP, having successfully delivered a multilink frame 
  3423. with C\ =\ 1 to the remote MLP, and having received a multilink frame with 
  3424. C\ =\ 1, could 
  3425. immediately transmit multilink frames with R\ =\ C\ =\ 0. However, to insure 
  3426. that the multilink frames with R\ =\ C\ =\ 0 are not discarded because 
  3427. they arrive at 
  3428. the remote MLP prior to the SLP acknowledgement of the reception of the 
  3429. C\ =\ 1 multilink frame, the MLP should use the same SLP as that which 
  3430. acknowledged 
  3431. receipt of the multilink frame with C\ =\ 1.)
  3432. .PP
  3433. When the initiating MLP receives a multilink frame with C = 1 without having 
  3434. received a multilink frame with R\ =\ 1, it will retransmit the multilink 
  3435. frame with R\ =\ 1 and restart its Timer\ MT3. 
  3436. .PP
  3437. When an MLP additionally receives one or more multilink frames with
  3438. R\ =\ 1 between receiving a multilink frame with R\ =\ 1 and transmitting a
  3439. multilink frame with C\ =\ 1, the MLP shall discard the extra multilink frames
  3440. with R\ =\ 1. When an MLP receives a multilink frame with C\ =\ 1, which 
  3441. is not a reply to a multilink frame with R\ =\ 1, the MLP shall discard 
  3442. the multilink 
  3443. frame with C\ =\ 1.
  3444. .PP
  3445. After an MLP transmits a multilink frame with C = 1 on one of its
  3446. SLPs, the MLP may receive a multilink frame with R\ =\ 1 from the remote 
  3447. MLP. The MLP shall regard the multilink frame with R\ =\ 1 as a new reset 
  3448. request and 
  3449. shall start the multilink resetting procedure from the beginning.
  3450. .PP
  3451. When Timer MT3 runs out, the MLP restarts the multilink resetting
  3452. procedure from the beginning. The value of Timer\ MT3 shall be large enough 
  3453. to include the transmission, retransmission and propagation delays in the 
  3454. SLPs, 
  3455. and the operation time of the MLP that receives a multilink frame with R\ =\ 1
  3456. and responds with a multilink frame with C\ =\ 1.
  3457. .RT
  3458. .sp 2P
  3459. .LP
  3460. 2.5.4.3
  3461.     \fITransmitting multilink frames\fR 
  3462. .sp 1P
  3463. .RT
  3464. .sp 1P
  3465. .LP
  3466. 2.5.4.3.1
  3467.     \fIGeneral\fR 
  3468. .sp 9p
  3469. .RT
  3470. .PP
  3471. The transmitting STE MLP shall be responsible for controlling the flow 
  3472. of packets from the packet level into multilink frames and then to the 
  3473. SLPs for transmission to the receiving STE MLP.
  3474. .PP
  3475. The functions of the transmitting STE MLP shall be to:
  3476. .RT
  3477. .LP
  3478.     1)
  3479.     accept packets from the packer layer;
  3480. .LP
  3481.     2)
  3482.     allocate multilink control fields, containing the
  3483. appropriate sequence number MN(S), to the packets;
  3484. .LP
  3485.     3)
  3486.     assure that MN(S) is not assigned outside the MLP transmit   window (MW);
  3487. .LP
  3488.     4)
  3489.     pass the resultant multilink frames to the SLPs for
  3490. transmission;
  3491. .LP
  3492.     5)
  3493.     accept indications of successful transmission
  3494. acknowledgements from the SLPs;
  3495. .LP
  3496.     6)
  3497.     monitor and recover from transmission failures or
  3498. difficulties that occur at the SLP sublayer; and
  3499. .LP
  3500.     7)
  3501.     accept flow control indications from the SLPs and take
  3502. appropriate actions.
  3503. .sp 1P
  3504. .LP
  3505. 2.5.4.3.2
  3506.     \fITransmission of multilink frames\fR 
  3507. .sp 9p
  3508. .RT
  3509. .PP
  3510. When the transmitting MLP accepts a packet from the packet layer, it shall 
  3511. place the packet in a multilink frame, set the MN(S) equal to MV(S), assure 
  3512. that MN(S) is not assigned outside the transmit window (MW), set V, S, 
  3513. R and C to\ 0, and then increment MV(S) by\ 1. 
  3514. .PP
  3515. In the following, incrementing send and receive state variables is in reference 
  3516. to a continuously repeated sequence series, i.e.,\ 4095 is\ 1 higher 
  3517. than 4094, and 0 is\ 1 higher than 4095 for modulo\ 4096 series.
  3518. .PP
  3519. If the MN(S) is less than MV(T) + MW, and the remote STE has not
  3520. indicated a busy condition on all available links, the transmitting MLP may
  3521. then assign the new multilink frame to an available link. The transmitting 
  3522. MLP shall always assign the lowest MN(S) unassigned 
  3523. .bp
  3524. .PP
  3525. multilink frame first. Also,
  3526. the transmitting MLP may assign a multilink frame to more than one link. 
  3527. When the SLP successfully completes the transmission of a multilink frame(s) 
  3528. by 
  3529. receiving an acknowledgement from the remote SLP, it shall indicate this 
  3530. to the transmitting MLP. The transmitting MLP may then discard the acknowledged 
  3531. multilink frame(s). As the transmitting STE receives new indications of
  3532. acknowledgements from the SLPs, MV(T) shall be advanced to denote the lowest
  3533. numbered multilink frame not yet acknowledged.
  3534. .PP
  3535. Whenever an SLP indicates that it has attempted to transmit a
  3536. multilink frame N2\ times, the MLP will then assign the multilink frame 
  3537. to the same or one or more other links, unless the MN(S) has been acknowledged 
  3538. on some previous link. The MLP shall always assign the lowest MN(S) frame 
  3539. first. 
  3540. .PP
  3541. \fINote\ 1\fR \ \(em\ If an MLP implementation is such that a multilink 
  3542. frame is transmitted on more than one link (e.g.,\ to increase the probability 
  3543. of 
  3544. successful delivery) there is a possibility that one of these multilink 
  3545. frames (i.e.,\ a duplicate) may be delivered to the remote MLP after an 
  3546. earlier one has been acknowledged [the earlier multilink frame would have 
  3547. resulted in the 
  3548. receiving remote MLP having incremented its MV(R) and the transmitting MLP
  3549. having incremented its MV(T)]. To ensure that an old duplicate multilink 
  3550. frame is not mistaken for a new frame by the receiving remote MLP, it is 
  3551. required 
  3552. that the transmitting MLP shall never send a new multilink frame with MN(S)
  3553. equal to MN(S)` \(em\ MW\ \(em\ MX, where MN(S)` is associated with a duplicate
  3554. multilink frame that is being transmitted on other SLPs, until all SLPs have
  3555. either successfully transferred the multilink frame or retransmitted the 
  3556. frame their maximum number of times. Alternatively, the incrementing of 
  3557. MV(T) may be withheld until all SLPs have either successfully transferred 
  3558. the multilink 
  3559. frame or retransmitted the frame their maximum number of times. These and 
  3560. other alternatives are for further study. 
  3561. .PP
  3562. Flow control is achieved by the window size parameter MW, and through busy 
  3563. conditions being indicated by the remote SLPs. 
  3564. .PP
  3565. The MLP will not assign a multilink frame with an MN(S) greater than MV(T)\ 
  3566. +\ MW\ \(em\ 1. At the point where the next multilink frame to be assigned 
  3567. has a MN(S)\ =\ MV(T)\ +\ MW, the MLP shall hold this and subsequent multilink 
  3568. frames until an indication of acknowledgement that advances MV(T) is 
  3569. received from the SLPs.
  3570. .PP
  3571. The remote MLP may exercise flow control of the MLP by indicating a
  3572. busy condition over one or more remote STE SLPs. The number of SLPs made 
  3573. busy will determine the degree of MLP flow control realized. When the MLP 
  3574. receives an indication of a remote SLP busy condition from one or more 
  3575. of its SLPs, the MLP may reassign any unacknowledged multilink frames that 
  3576. were assigned to 
  3577. those SLPs. The MLP will assign the multilink frames containing the lowest
  3578. MN(S) to an available SLP as specified above.
  3579. .PP
  3580. In the event of a circuit failure, an SLP reset or SLP disconnection, all 
  3581. multilink frames unacknowledged on an SLP link shall be retransmitted on 
  3582. an operational SLP(s) which is(are) not in the busy condition. 
  3583. .PP
  3584. \fINote\ 2\fR \ \(em\ The action to be taken on the receipt of an RNR frame by
  3585. the SLP whose unacknowledged multilink frames have been removed for further
  3586. study.
  3587. .PP
  3588. \fINote\ 3\fR \ \(em\ The means of detecting transmitting MLP malfunctions
  3589. (e.g.,\ sending more than MW multilink frames) and the actions to be taken 
  3590. are for further study. 
  3591. .RT
  3592. .sp 1P
  3593. .LP
  3594. 2.5.4.4
  3595.     \fIReceiving multilink frames\fR 
  3596. .sp 9p
  3597. .RT
  3598. .PP
  3599. Any multilink frame less than two octets in length shall be
  3600. discarded by the receiving STE.
  3601. .PP
  3602. \fINote\ 1\fR \ \(em\ The procedures to be followed by the receiving STE 
  3603. when V and/or S is equal to\ 1 are for further study. 
  3604. .PP
  3605. When the STE receives multilink frames from one of its SLPs, the STE will 
  3606. compare the multilink sequence number MN(S) of the received multilink 
  3607. frame to its multilink receive state variable MV(R), and act on the frame as
  3608. follows:
  3609. .RT
  3610. .LP
  3611.     a)
  3612.     If the received MN(S) is equal to the current value of
  3613. MV(R), i.e., is the next expected in\(hysequence multilink frame,
  3614. the MLP delivers the packet to the packet layer.
  3615. .LP
  3616.     b)
  3617.     If the MN(S) is greater than the current value of MV(R) but
  3618. less than [MV(R)\ +\ MW\ +\ MX], the MLP keeps the received
  3619. multilink
  3620. frame until condition\ a) is met, or discards it if it is a
  3621. duplicate.
  3622. .LP
  3623.     c)
  3624.     If the MN(S) is other than that in a) and b) above, the
  3625. multilink frame is discarded.
  3626. .PP
  3627. \fINote\ 2\fR \ \(em\ In case c above the recovery from the desynchronization 
  3628. greater than MX between the local and the remote MLP, i.e., the value of 
  3629. MN(S) assigned to new multilink frames at the remote MLP is higher than 
  3630. MV(R)\ +\ MW\ +\ MX at the local MLP, is for further study.
  3631. .bp
  3632. .PP
  3633. On receipt of a multilink frame, MV(R) is incremented in the
  3634. following way:
  3635. .RT
  3636. .LP
  3637.     i)
  3638.     If MN(S) is equal to the current value of MV(R), the MV(R)
  3639. is incremented by the number of consecutive in\(hysequence
  3640. multilink frame received. If additional multilink frames are
  3641. awaiting delivery pending receipt of a multilink frame with
  3642. MN(S) equal to MV(R), then Timer\ MT1 (see \(sc\ 2.5.5.1) is
  3643. restarted; otherwise MT1 is stopped.
  3644. .LP
  3645.     ii)
  3646.     If MN(S) is greater than the current value of MV(R) but
  3647. less than MV(R)\ +\ MW, MV(R) remains unchanged. Timer\ MT1 is
  3648. started, if not already running.
  3649. .LP
  3650.     iii)
  3651.     If MN(S) is \(>=" MV(R) + MW but < MV(R) + MW + MX, MV(R) is
  3652. incremented to 
  3653. MN(S)\ \(em\ MW\ +\ 1 and then the packet layer may
  3654. be informed of the packet loss at the original value of
  3655. MV(R). As MV(R) is being incremented, if the multilink frame
  3656. with MN(S)\ =\ MV(R) has not yet been received, the packet layer
  3657. may be informed of the packet loss also; if the multilink
  3658. frame with MN(S)\ =\ MV(R) has been received, it is delivered to
  3659. the packet layer. After MV(R) reaches MN(S) \(em MW + 1, it may
  3660. then be incremented further as above until the first
  3661. unacknowledged MN(S) is encountered (see Figure\ 4/X.75).
  3662. .LP
  3663.     iv)
  3664.     If the MN(S) is other than that in i), ii) and iii)
  3665. above, MV(R) remains unchanged.
  3666. .PP
  3667. If Timer MT1 runs out, MV(R) is incremented to MN(S) of the next multilink 
  3668. frame awaiting delivery to the packet layer and then the packet layer may 
  3669. be informed of the packet loss at the original MV(R). The procedure follows 
  3670. i) and a) above as long as there are consecutive in\(hysequence multilink 
  3671. frames which have been received. 
  3672. .PP
  3673. When flow control of the other MLP is desired, one or more SLP(s) may be 
  3674. made to indicate a busy condition. The number of remote SLPs made busy 
  3675. determines the degree of flow control realized.
  3676. .PP
  3677. If the MLP can exhaust its receive buffer capacity before resequencing 
  3678. can be completed, Timer\ MT2 (see \(sc\ 2.5.5.2 below) may be implemented. 
  3679. Whenever a busy condition is indicated by the MLP on all its SLPs, and 
  3680. multilink frames at the MLP are awaiting resequencing, Timer\ MT2 shall 
  3681. be started. When the busy condition is cleared on one or more SLPs by the 
  3682. MLP, Timer\ MT2 shall be 
  3683. stopped.
  3684. .PP
  3685. If Timer MT2 runs out, the multilink frame with MN(S) = MV(R) is
  3686. blocked and shall be considered lost. MV(R) shall be incremented to the next
  3687. sequence number not yet received, and the packets contained in multilink
  3688. frames with intervening multilink sequence numbers are delivered to the 
  3689. packet layer. Timer\ MT2 shall be restarted if the busy condition remains 
  3690. in effect on all SLPs and more multilink frames are awaiting resequencing. 
  3691. .RT
  3692. .LP
  3693. .rs
  3694. .sp 20P
  3695. .ad r
  3696. \fBFigure 4/X.75, p. 
  3697. .sp 1P
  3698. .RT
  3699. .ad b
  3700. .RT
  3701. .LP
  3702. .bp
  3703. .sp 1P
  3704. .LP
  3705. 2.5.4.5
  3706.     \fIRetransmission of multilink frames\fR 
  3707. .sp 9p
  3708. .RT
  3709. .PP
  3710. If an SLP has retransmitted a multilink frame MN1 times, the STE
  3711. will then assign the multilink frame to the same or one or more other links,
  3712. unless the MN(S) has been acknowledged on some previous link. The STE shall
  3713. always reassign the lowest MN(S) frame first. The first SLP transmits the 
  3714. frame N2\ times, regardless of the value of MN1. 
  3715. .PP
  3716. \fINote\fR \ \(em\ The procedures associated with the reassigning of multilink 
  3717. frames from a link of poor quality (e.g.,\ before N2\ transmissions) to 
  3718. other 
  3719. links are for further study.
  3720. .RT
  3721. .sp 1P
  3722. .LP
  3723. 2.5.4.6
  3724.     \fITaking an SLP out of service\fR 
  3725. .sp 9p
  3726. .RT
  3727. .PP
  3728. An SLP may be taken out of service for maintenance,
  3729. traffic, or performance considerations.
  3730. .PP
  3731. An SLP is taken out of service by disconnecting at the physical
  3732. layer or the data link layer. Any outstanding multilink frames will be 
  3733. treated as in \(sc\ 2.5.4.1. The usual procedure would be to flow control 
  3734. the remote SLP by an RNR, and then to disconnect logically the local SLP 
  3735. (see \(sc\ 2.4.4.3 above). 
  3736. .PP
  3737. If Timer T1 has run out N2 times and the SLP resetting procedure is
  3738. unsuccessful, then the SLP will enter the disconnected phase, taking the SLP
  3739. out of service (see \(sc\(sc\ 2.4.5.8 and\ 2.4.7.2 above).
  3740. .PP
  3741. \fINote\fR \ \(em\ In the case when all SLPs are out of service, the recovery
  3742. mechanism is based on initiating the MLP reset procedure. Additional recovery 
  3743. procedures are for further study. 
  3744. .RT
  3745. .sp 2P
  3746. .LP
  3747. 2.5.5
  3748.     \fIList of multilink system parameters\fR 
  3749. .sp 1P
  3750. .RT
  3751. .sp 1P
  3752. .LP
  3753. 2.5.5.1
  3754.     \fILost\(hyframe timer MT1\fR 
  3755. .sp 9p
  3756. .RT
  3757. .PP
  3758. Timer MT1 is used at a receiving STE to provide a means to identify during 
  3759. low traffic periods that the multilink frame with MN(S) equal to MV(R) 
  3760. is lost. 
  3761. .RT
  3762. .sp 1P
  3763. .LP
  3764. 2.5.5.2
  3765.     \fIGroup busy timer MT2\fR 
  3766. .sp 9p
  3767. .RT
  3768. .PP
  3769. Timer MT2 is provided at a receiving STE to identify a \*Qblocked\*U
  3770. multilink frame condition (e.g.,\ a buffer exhaust situation) that occurs 
  3771. before required resequencing can be accomplished. MT2 is started when all 
  3772. SLPs are 
  3773. busy and there are multilink frames awaiting resequencing. If MT2 runs out
  3774. before the \*Qblocked\*U multilink frame MV(R) is received, the \*Qblocked\*U 
  3775. multilink frame(s) is(are) declared lost. MV(R) is incremented to the value 
  3776. of the next in\(hysequence multilink frame to be received, and any packets 
  3777. intervening 
  3778. multilink frames are delivered to the packet layer.
  3779. .PP
  3780. \fINote\fR \ \(em\ MT2 may be set to infinity; e.g., when the receiving STE
  3781. always has sufficient storage capacity.
  3782. .RT
  3783. .sp 1P
  3784. .LP
  3785. 2.5.5.3
  3786.     \fIMLP reset confirmation timer MT3\fR 
  3787. .sp 9p
  3788. .RT
  3789. .PP
  3790. Timer MT3 is used by the MLP to provide a means of identifying that the 
  3791. remote MLP multilink frame with the C\ bit set to\ 1 that is expected 
  3792. following the transmission of the MLP multilink frame with R\ bit set to\ 
  3793. 1 has not been received. 
  3794. .RT
  3795. .sp 1P
  3796. .LP
  3797. 2.5.5.4
  3798.     \fIRetransmission attempts MN1\fR 
  3799. .sp 9p
  3800. .RT
  3801. .PP
  3802. MN1 has a value between zero and the smallest N2 over all SLPs
  3803. inclusive. If a multilink frame is to be retransmitted at the SLP sublayer, 
  3804. MN1 retries indicates when action may be taken at the MLP sublayer. 
  3805. .RT
  3806. .LP
  3807. .bp
  3808.